Patrick Freudenstein

Web Engineering for Workflow-based ApplicationsModels, Systems and Methodologies

Web Engineering for Workflow-based ApplicationsModels, Systems and Methodologies

by Patrick Freudenstein

Universittsverlag Karlsruhe 2009 Print on Demand

ISBN: 978-3-86644-427-0

Impressum

Universittsverlag Karlsruhec/o UniversittsbibliothekStrae am Forum 2D-76131 Karlsruhewww.uvka.de

Dissertation, Universitt Karlsruhe (TH)Fakultt fr InformatikTag der mndlichen Prfung: 14.07.2009Referenten: Prof. Dr. Wilfried Juling, Prof. Dr. Hartmut Schmeck

Dieses Werk ist unter folgender Creative Commons-Lizenz lizenziert: http://creativecommons.org/licenses/by-nc-nd/3.0/de/

Acknowledgements

Workingtowardsthisthesis,IreceivedmanifoldsupportforwhichIamverygratefulandwouldliketoexpressmyappreciationfor.

Firstofall,IwouldliketothankmysupervisorProf.Dr.WilfriedJulingforgivingmethe great opportunity to join his research group at the Karlsruhe Institute ofTechnologys(KIT)InstituteofTelematicsaswellasforleavingmevaluablefreedomand scope formy research. Furthermore, Iwould like to thank Prof.Dr.HartmutSchmeckforhisworkandassistanceassecondrefereeaswellasProf.Dr.AndreasOberweisandProf.Dr.SebastianAbeckforactingasexaminersinmydisputation.

DuringmytimeattheKIT,Ihadthelucktoworkwithexcellentandhighlymotivatedcolleagues and students in a friendly and inspiring atmosphere, for which I amparticularlygrateful. Iwould liketo thankmycolleagues JanBuck,Prof.Dr.MartinGaedke,FredericMajer,Dr.JohannesMeineckeandDr.MartinNubaumerfromtheITManagement andWebEngineeringResearchGroup (MWRG) for thenumerousstimulatingdiscussionsandfruitful jointwork.Iwouldalso liketothankInaDvorakfor assisting me with administrative work and for her cheerful way of resolvingproblems. I am thankful to Martin N. for managing the groups transition sosmoothlyaswellasforhiscontinuoushelpfulnessandsupport,proficientadviceandour successful collaboration throughout the years. I am particularly thankful toFredericwhostoodbymysidethroughoutallthehardworkandmadeitmuchmoreenjoyable.Beingmybest friend,hehasalsobeenagreatmentor,alwaysavailablefordiscussingquestionsandauniquesourceofcreativity.

Furthermore, I am thankful tomy graduate students Florian Allerding, ChristophAugenstein, Marko Bttger, Jan Buck, Thorsten Hllrigl, Kristina Jochim, LeilaKarademir,NikolayOrozov, Frank Schell,Denny Setiawanand FrdricWenzel fortheirhighenthusiasm,commitmentandvaluablecontributionstomyresearch.

TheprojectKarlsruhesIntegratedInformationManagement(KIM)andthepeopleinvolvedthereinpresentedacentralpillarofmyworkattheKIT.Asadynamicandmotivated team,wehave succeedednumerousambitiousaccomplishments,oftenbeyondtheteammembersactualresponsibilities.Asrepresentativesfortheentireteam,Iwould liketothankJanBuck,ThorstenHllrigl,StefanLink,LeiLiu,FredericMajer,AxelMaurer,ChristofMomm,DanielRied,FrankSchell,WilhelmSieversand

ii Acknowledgements

Marekillerforthegreattime,the jointeffortsandthefriendlyatmosphere intheKIMLabs.

Moreover,Iamthankfultoallmyfriendsandformercolleagueswhohavesupportedmeinmypersonaldevelopmentandencouragedmeinmydecisiontotakethepathtowardsdoing aPhD. In this regard, Iwould like toparticularly thankDr.DietgerBansberg,Dr.StefanFeyrerandSabineSchnarrenbergerfortheirgreatsponsorship,mentoringanddeepfriendship.

Finally,IwouldliketoexpressmyparticulargratitudetomyparentsJuttaandGerdfor conveyingme the values and principleswhichmademy path of life and thisthesis possible in the first place. They, togetherwithmy brotherMoritz andmygrandparents,havealwaysandunconditionallysupportedandencouragedmeandenriched my life with kindness and happiness. I have special thanks for mygrandfatherWernerwho sparkedmy interest inprogrammingalready inmyearlychildhoodandthuslaidthefoundationformydevelopmentasacomputerscientist.Ilearntsomuchfromhimandhewillalwaysbeagreatrolemodelforme.

Above all, I would like to thank my fiance Dana for her unique and unlimitedunderstandingduringtheseintenseyears.Shehasalwayssupportedandencouragedmeandinfectedmewithherhappiness.Thankyousomuch,Dana!

Zusammenfassung

WorkflowbasierteWeb Anwendungen stellen eine eigenstndige, stark an BedeutunggewinnendeGenerationvonAnwendungendar,dieaufdenTechnologienundStandards desWorldWideWeb Consortiums (W3C) aufbauen sowieDienste undInhalteberdenBrowseranbieten.ZuderenEvolutionhabenprimrdreiFaktorenbeigetragen: Erstens, die weitreichende, durch erfolgreiche StandardisierungsbemhungengetriebeneAkzeptanzundEtablierungdesKonzeptsderserviceorientierten Architektur (SOA). Zweitens, die unter dem Schlagwort Web 2.0subsummierte neue Generation hochgradig interaktiver Web Anwendungen undBasistechnologien.Drittens,derausSichtvonUnternehmendringendeBedarfeinerdurchgngigen und flexiblen ITbasierten Geschftsprozessuntersttzung berSystem und Organisationsgrenzen hinweg. Vor diesem Hintergrund bietenworkflowbasierte Web Anwendungen eine homogene, integrative und plattformunabhngig verfgbare Benutzungsschnittstelle zur effektiven Abwicklung vonGeschftsprozessen.

Aus technischer Sicht ergeben sich hierdurch vielfltige Anforderungen, die zurErzielung einer effizienten und effektiven EntwicklungworkflowbasierterWebAnwendungenzuadressierensind.DiesbetrifftinsbesonderedieBereichederProzesssteuerungundderBenutzungsschnittstellesowieweitere,ausdenspezifischenCharakteristikavonWebAnwendungenresultierendeHerausforderungen.Hierzuzhlenbeispielsweise kurze Entwicklungs und Evolutionszyklen, die zunehmende Bedeutung von sthetik und Benutzungsfreundlichkeit, die Vielfalt an Zugriffskanlensowie die ausgeprgteHeterogenitt der zuknftigenNutzer und der an der EntwicklungbeteiligtenPersonen (engl. Stakeholder).DesWeiteren stellendieVielzahlunterschiedlicherEntwicklungsArtefaktesowiedie inhrenteDokumentenzentriertheitdesWebgrundlegendeSpezifikavonWebAnwendungendar.

Neben den genannten Problemstellungen kommt aus einer kommunikations undkollaborationsorientiertenSichtweiseder intensivenundeffektivenEinbindungvonStakeholderneinezentraleBedeutungzu.InverschiedenenStudienwurdediemangelhafteEinbindungundKommunikationmitallenrelevantenPersonengruppenalseinerderHauptgrndefrdasScheiternvonSoftwareprojektenidentifiziert.Diesgiltinsbesondere imKontextworkflowbasierterWebAnwendungen, frdieeineeffektiveKommunikationbezglichderabzubildendenGeschftsprozesseundAktivitten

iv Zusammenfassung

wesentlichist.DarberhinauskannderdabeirelevantePersonenkreisentsprechendderKomplexittzubetrachtenderGeschftsprozessehochgradigheterogensein.

VordiesemHintergrundprsentiertdievorliegendeDissertationeinenmodellgetriebenenAnsatzzurKonstruktionworkflowbasierterWebAnwendungenmitbesonderemFokusaufdieeffizienteundeffektiveEinbindungvonStakeholdern.AufbauendaufeinersystematischenAnalysederProblemdomnewurdenneuartigeKonzepte,Modelle,SystemeundMethodikenentwickeltundevaluiert,dieeinenwesentlichenBeitrag zumaktuellenStandderTechnikdarstellen. ImEinzelnen liefertdieArbeitfolgendeBeitrge:

WebEngineeringDSLRahmenwerk:AlskonzeptionelleGrundlage freine intensivere und effektivere Zusammenarbeit mit Stakeholdern bei der Entwicklung vonWeb Anwendungen wird ein neuartiger modellgetriebener Konstruktionsansatzprsentiert, der auf domnenspezifischen Sprachen (DSLs) fut. Ziel ist es,Stakeholder in die Lage zu versetzen, eigenstndig Teile der Lsung validieren,modifizieren und auch spezifizieren zu knnen. Das Rahmenwerk sieht dieVerwendungverschiedener,stark fokussierterDSLs frdieeinzelnenAspekteeinerWeb Anwendung vor. Dabei erlaubt die DSLSpezifikation die Integration aufbestimmteStakeholdergruppenundProzessphasenzugeschnittenerNotationenundWerkzeuge. Dadurch kann deren Erlernbarkeit und Anwendbarkeit sowohl frEntwickler als auch fr Stakeholder mit geringen ITKenntnissen signifikantverbessertwerden.DervorgestellteAnsatzbieteteineneuartigeAlternativezudenexistierenden schwergewichtigen und monolithischen Modellierungsanstzen imWeb Engineering, die primr fr die Verwendung innerhalb von Entwicklerteamsentworfen wurden. Web Anwendungen werden somit evolutionr durchKompositionspezifischerSoftwarekomponentenundderenKonfigurationdurchDSLProgramme in Form von Stakeholderorientierten Modellen konstruiert undweiterentwickelt.

Der WorkflowDSLAnsatz: Eine Anwendung des DSLKonzepts zur StakeholderorientiertenundvollstndigmodellgetriebenenKonstruktionworkflowbasierterWebAnwendungen stelltdieWorkflowDSLdar.DurchdenAnsatzwirdeineholistischeSpezifikation von WorkflowAspekten und webbasierten BenutzungsschnittstellenfrdieeffizienteundeffektiveAbwicklungvonWorkflowAufgabenmglich.DasderDSLzugrundeliegendeformalisierteSchemastellteineneuartige,aufweitverbreitetenStandardsundderennativenErweiterungsmechanismenbasierende,konzeptionelleGrundlagezurintegriertenSpezifikationdieserAspektedar.DieWorkflowDSLerlaubt die iterative Modellierung workflowbasierter Web Anwendungen mittelsverschiedenster bekannter Notationen und Werkzeuge in Abhngigkeit des EntwicklungsfortschrittsundderBedrfnissederjeweiligenStakeholdergruppe.FrdieeinfacheModellierungeinzelnerWorkflowAktivittenwirdeinKatalogwebspezifischerAktivittsbausteinewiezumBeispieldialogbasierte Interaktion,Datenprsentation oderWeb Service Kommunikation eingefhrt. Fr jeden dieser hochgradigwiederverwendbarenBausteinewirddieminimalbentigte,typspezifischeKonfigurationsmengeallgemeingltigundimplementierungsunabhngigdefiniert.

ZurErzielungeinesneuartigenGradsanModellkontinuittundkonsistenzwirdeinneuesKonzeptzurberwindungderHeterogenittexistierenderGeschftsprozess

Zusammenfassung v

modellierungssprachenvorgestellt.DiesesbisherungelsteProblemwirddurcheinewohldefinierte Menge allgemeiner Geschftsprozess und WorkflowKonzepteadressiert, die von individuellen Notationen und Sprachen abstrahiert und dieGrundlage zur Erzielung semantischer Kongruenz darstellt. Obwohl dadurch nichtalletheoretischmglichenKonstrukteeinbezogenwerden,besttigenumfangreicheempirischeEvaluationeneineausreichendeAbdeckungvon inderPraxisauftretendenGeschftsprozessmodellen.DaraufaufbauendwirdeinerweiterbaresRahmenwerk fr verlustfreie, bilaterale Modelltransformationen prsentiert, wodurchschlielicheinnotationsbergreifenderModellierungsansatzerzieltwird.

Die technischeUntersttzungsplattform verwirklicht die vollstndig automatisierteKonstruktion workflowbasierter Web Anwendungen auf Basis eines gegebenenWorkflowDSLModells.DasdabeirealisierteArchitekturkonzept istdienstorientiertausgelegt,wodurchdieGrundlagezurRealisierungfderativerSzenariensowiemultimodaler Partizipation geschaffenwird. Der automatisierte Konstruktionsprozess,diekonsistentePropagierungvonnderungensowiedieMglichkeiteinesdetaillierten,DSLbasierten Entwurfs derwebbasiertenBenutzungsschnittstelle zur LaufzeitfrderneineagileundevolutionsorientierteEntwicklungsmethodik.

Der DialogDSLAnsatz: Effektive dialogbasierte Benutzerinteraktion stellt denzentralen Baustein des oben genannten Katalogs zurwebbasiertenUntersttzungvonGeschftsprozessaktivittendar.DieDialogDSLstelltneuartigeModelle,WerkzeugeundeinVorgehensmodellzurvollstndigmodellgesttztenEntwicklungkomplexer und hochgradig dynamischer Dialogkomponenten bereit. Dabei stehen AspektederBenutzungsfreundlichkeitsowiedieeffektiveEinbindungvonStakeholdernim Vordergrund. Whrend existierende Lsungen immer noch eine traditionelle,berwiegend prsentations und technikgetriebene Entwicklungsmethodik verfolgen,lenktdieDialogDSLbereitszurEntwurfszeitdenFokusaufdieBercksichtigungund Integration vonAspekten derBenutzungsfreundlichkeit und insbesondere dynamischemVerhalten.DadurchwerdendiePotenzialewebbasierterDialogeeffektiver genutzt und eine kognitive berlastung zuknftiger Nutzer vermieden. Einweitererwesentlicher Fortschritt zum gegenwrtigen Stand der Technik stellt diehervorragendeAnwendbarkeitdesAnsatzes frStakeholdermitwenigoderkeinenITKenntnissendar,diedurchformaleempirischeExperimentenachgewiesenwurde.IndiesemKontextwurdenauchsignifikanteEffizienzsteigerungengegenberexistierenden Anstzen nachgewiesen. Die resultierenden Dialogmodelle sind plattformunabhngig undwerden zur Laufzeit dynamisch entsprechend denCharakteristikader anfragenden Clients transformiert. Zur Untersttzung einer agilen und evolutionsorientierten Entwicklungsmethodik untersttzt der Ansatz die automatischeGenerierungwebbasierterDialoge,beispielsweise entsprechend desW3C XFormsStandards,sowiediedurchgngigmodellbasierteSpezifikationmitHilfeeineswebbasiertenEditors.

Der Web EngineeringReuse SphereAnsatz:Besondersmodellund komponentenbasierteAnstze,wiedieindieserArbeitvorgestellten,knnenvoneinereffektivenWiederverwendungsuntersttzungprofitieren.UmWiederverwendungspotenziale nicht wie bisher nur auf eine bestimmte Art von Artefakten oder Entwicklungsmethodikzubeschrnken,stelltdieWebEngineeringReuseSphereeinenholistischen, artefakt und methodenbergreifenden Ansatz fr die stark heterogene

vi Zusammenfassung

WebEngineeringDomnedar.EinanPrinzipienausdemBereichEnterpriseApplicationIntegration(EAI)angelehnteReferenzarchitekturuntersttztnebendergeplanten auch die spontane Wiederverwendung, wodurch Artefakte whrend ihresgesamten Lebenszyklus zurWiederverwendungnutzbarwerden.Zur semantischenVerknpfung und Homogenisierung der verschiedenen ArtefaktTypen und WebEngineeringMethodikenwurdeaufBasisvonSemanticWebStandardseineOntologie frdieProblemdomneentwickelt.DabeiwirddieBercksichtigungvonStakeholderFhigkeiten als Schlsselfaktor fr die Effektivitt der Wiederverwendungaufgefasst,d.h.dieBefhigungwiederverwendbareArtefaktezuverstehen,zuevaluierenundggf.anzupassenund zuverwenden.DemzufolgewerdenaufBasisderOntologieneuartigewissensbasierteSuchstrategienrealisiert,dieauchStakeholderohneExpertenwissen indieLageversetzen,effizientgeeigneteMethodikenundArtefakte fr gegebene Probleme und in bereinstimmung mit ihren individuellenFhigkeiten zu finden. InAnbetracht aktuellerKonsolidierungsund Interoperabilittsinitiativen imWeb Engineering stellt der Ansatz einenwertvollen Beitrag zurtatschlichen Verwirklichung methodenbergreifender Wiederverwendung dar.Darber hinaus bildet er auch eine ideale Ergnzung des Web Engineering DSLRahmenwerks, indem er Stakeholder beim Finden individuell geeigneter DSLs,Modellierungsnotationen,WerkzeugeundassoziierterArtefakteuntersttzt.

Die indieserDissertationvorgestelltenneuartigenKonzepte,Modelle,SystemeundMethodiken stellen einen wesentlichen Fortschritt zur effizienten und effektivenEntwicklungworkflowbasierterWebAnwendungenmitStakeholderndar.Sieadressieren erfolgreich die identifizierten Anforderungen und bislang ungelsten Probleme.DievorgestelltenAnstzewurdenerfolgreich implementiertund inverschiedenenSzenarienevaluiert.Diesgeschah sowohldurch formaleempirischeStudienund Experimente als auchdurchden Einsatz in realenProjekten. In beiden FllenkonntendeutlicheVerbesserungenhinsichtlichderEffizienzundEffektivittderEntwicklung sowie der intensiven Einbindung von Stakeholdern festgestellt werden.DarberhinauskonntendieErgebnissedurchzahlreichePublikationenauf internationalen Konferenzen, Workshops und Zeitschriften mit Forschern aus der WebEngineeringDisziplinundangrenzendenGebietendiskutiertwerden.

Contents

Acknowledgements.................................................................................................i

Zusammenfassung..................................................................................................iii

Contents................................................................................................................vii

1 Introduction....................................................................................................1

1.1 RESEARCHQUESTIONSANDCONTRIBUTIONS............................................................2

1.2 RESEARCHCONTEXTANDSCOPE............................................................................7

1.3 THESISSTRUCTURE..............................................................................................8

2 ProblemScope..............................................................................................11

2.1 STAKEHOLDERCOLLABORATIONINTHEWEBENGINEERINGFIELD...............................11

2.2 WORKFLOWBASEDWEBAPPLICATIONS................................................................12

2.2.1 TechnicalChallenges.......................................................................................................14

2.2.2 StakeholderCollaborationforWorkflowbasedWebApplications................................17

2.2.3 RequirementsCatalogfortheDimensionWorkflow......................................................21

2.3 WEBBASEDDIALOGSASPRIMARYINTERACTIONMEDIUMS......................................22

2.3.1 RequirementsCatalogfortheDimensionDialog............................................................25

2.4 EFFECTIVEREUSE..............................................................................................26

2.4.1 RequirementsCatalogfortheDimensionReuse............................................................28

3 StateoftheArt..............................................................................................29

3.1 DIMENSIONWORKFLOW....................................................................................29

3.1.1 ObjectOrientedHypermediaDesignMethod(OOHDM)................................................29

3.1.2 WebModelingLanguage(WebML)................................................................................31

3.1.3 UMLbasedWebEngineering(UWE)..............................................................................32

3.1.4 IBMWebSphereSuite.....................................................................................................34

3.2 DIMENSIONDIALOG..........................................................................................37

3.2.1 ObjectOrientedHypermediaDesignMethod(OOHDM)................................................37

viii Contents

3.2.2 WebModelingLanguage(WebML)................................................................................38

3.2.3 UMLbasedWebEngineering(UWE)..............................................................................39

3.2.4 IBMLotusFormsDesigner..............................................................................................40

3.3 DIMENSIONREUSE............................................................................................42

3.3.1 ScientificReuseApproachesfortheWebEngineeringDomain......................................42

3.3.2 CommercialSolutions.....................................................................................................44

3.4 EVALUATIONRESULTSANDCONCLUSION...............................................................45

4 WebEngineeringforWorkflowbasedApplicationsADSLApproach.........51

4.1 THEWEBENGINEERINGDSLFRAMEWORK............................................................51

4.1.1 DSLsEvolutionaryWebDevelopmentforandwithReuse...........................................52

4.1.2 TechnicalPlatform..........................................................................................................56

4.2 OVERVIEWOFSOLUTIONELEMENTS.....................................................................57

5 ConstructingWorkflowbasedWebApplicationswithStakeholders............61

5.1 THEWORKFLOWDSLATAGLANCE......................................................................62

5.1.1 ElementsoftheWorkflowDSL........................................................................................62

5.1.2 EvolutionaryProcessModel............................................................................................63

5.2 THEDSMPROCESSINTERMEDIATELANGUAGE....................................................65

5.2.1 TheXMLProcessDefinitionLanguageasFoundationfortheDSM................................66

5.2.2 CatalogofActivityBuildingBlocks(ABBs)......................................................................68

5.2.3 ExtendingXPDLtowardsWebspecificConcerns............................................................72

5.3 THEDIMSMULTINOTATIONALMODELINGWITHSTAKEHOLDERS...........................76

5.3.1 SimpleSequenceOnly(SSO)withMicrosoftWord.........................................................78

5.3.2 BusinessProcessModelingNotation(BPMN)withMicrosoftVisio................................79

5.3.3 UMLActivityDiagramswithIBMRationalSoftwareArchitect.......................................82

5.3.4 PetriNetswithINCOME2010..........................................................................................86

5.4 MODELTRANSFORMATIONFRAMEWORK...............................................................91

5.4.1 StrategyforEfficientandEffectiveModelTransformations...........................................91

5.4.2 TheCoreElementsSet(CES)Concept.............................................................................95

5.4.3 HorizontalModelTransformationsThePetriNetDIM................................................99

5.4.4 VerticalModelTransformationsTheXOMLWorkflowLanguage.............................106

5.4.5 CompleteCatalogofDIMMappings.............................................................................113

5.5 TECHNICALPLATFORM.....................................................................................115

5.5.1 TechnicalPlatformfortheModelTransformationFramework....................................116

5.5.2 WorkflowExecutionPlatform.......................................................................................120

5.5.3 AutomatedApplicationConstruction:FromModelingtoExecution............................126

5.5.4 SupportforFederativeScenarios..................................................................................129

Contents ix

5.6 SUMMARY.....................................................................................................131

6 ConstructingAdvancedWebbasedDialogs..................................................135

6.1 THEDIALOGDSLATAGLANCE..........................................................................135

6.1.1 ElementsoftheDialogDSL...........................................................................................136

6.1.2 EvolutionaryProcessModel..........................................................................................137

6.2 THEDOMAINSPECIFICMODEL(DSM)...............................................................138

6.3 THEDOMAININTERACTIONMODEL(DIM)..........................................................140

6.3.1 Partitions&TransitionsModelingTier.........................................................................141

6.3.2 AppearanceModelingTier............................................................................................142

6.4 MODELTRANSFORMATIONS..............................................................................143

6.4.1 UserAgentrelatedModelAdaptations.......................................................................143

6.4.2 ModeltoCodeTransformations..................................................................................144

6.5 TECHNICALPLATFORM.....................................................................................145

6.5.1 TheWebbasedDIMEditor...........................................................................................146

6.5.2 TheSolutionBuildingBlock(SBB).................................................................................149

6.6 SUMMARY.....................................................................................................151

7 TheWebEngineeringReuseSphere.............................................................153

7.1 THESPHERECONCEPT......................................................................................154

7.2 THESEMANTICCORE:THEWEBENGINEERINGREUSEONTOLOGY............................155

7.2.1 OverviewoftheWebEngineeringReuseOntology......................................................156

7.2.2 TheConceptsKnowledgeandStakeholders.................................................................158

7.2.3 TheConceptsArtifact,Methodology,ProcessandProduct..........................................159

7.2.4 TheConceptsResolutionStrategy,ModelingTechnique&Software...........................160

7.3 EFFECTIVESEARCHANDINTEGRATION.................................................................162

7.4 STORINGARTIFACTSWITHRICHMETADATA.........................................................163

7.5 REFERENCEARCHITECTUREFRAMEWORK.............................................................165

7.6 CROSSMETHODOLOGICALREUSEWITHSTAKEHOLDERSINPRACTICE........................168

7.6.1 FindingStakeholderTailoredResolutionStrategiesandArtifacts...............................168

7.6.2 StakeholderOrientedFacettedSearchandBrowsingFacilities...................................171

7.7 SUMMARY.....................................................................................................174

8 Evaluation....................................................................................................177

8.1 EMPIRICALEVALUATIONOFWORKFLOWDSLCONCEPTS........................................178

8.1.1 ExpressivenessoftheCESinRealWorldProcessModels.............................................178

8.1.2 CoverageofRealWorldProcessActivitiesbytheABBCatalog....................................182

8.2 WORKFLOWDSLCONCEPTSAPPLIEDINTHEKIMPROJECT....................................183

x Contents

8.2.1 FSMbasedModelingofUserInteractionWorkflowsusingABBs................................185

8.2.2 TechnicalFrameworkforExecutingUIWorkflowsinWebPortals...............................186

8.2.3 Experiences...................................................................................................................188

8.3 FORMALEMPIRICALEVALUATIONOFTHEDIALOGDSL...........................................189

8.3.1 ExperimentalEvaluationofDevelopmentandChangeEfficiency................................189

8.3.2 SurveybasedEvaluationofStakeholderAdequacy......................................................196

9 ConclusionandOutlook...............................................................................203

ListofFigures.......................................................................................................209

ListofTables........................................................................................................213

Bibliography........................................................................................................215

Index....................................................................................................................235

1 Introduction

Since its inception in 1991, the World Wide Web has evolved rapidly from adecentralized information medium to a platform for complex and distributedapplications. Likewise, the requirements and expectations for Webbasedapplications have increased substantially. The first genre of Web applicationsinitiatedtheWebstransitionfromstatichypertextdocuments(theStaticWeb)todynamically generated Web pages based on content stored in databases (theDynamic Web) (Rossi, Pastor, Schwabe et al. 2008). This allowed for simplecustomizationrelated features and limited user interactivity, whereby the Webapplicationitselfwastheonlyaccesschanneltotheinformationavailabletherein.

Thecontinuousadoptionof theServiceOrientedArchitecture (SOA)paradigmandWeb 2.0 technologies in the last few years resulted in anew classofWebbasedapplications(O'Reilly2005;Phifer2006).Suchapplicationsarehighlyinteractiveandusercentered, provide a rich user interface and are constructed based on SOAconceptsandstandards.Atthesametime,companiesstartedtotakeadvantageofmaturingSOArelatedstandardsandtechnologiesinordertorealizeintegratedendtoend business processes spanning a great diversity of heterogeneous systems,organizations,and job roles.Todayscompaniesvisionof increasedbusinessagilityresults in Business ProcessManagement Suites being one of the fastest growingsoftware infrastructure markets with an estimated annual growth rate of 25%(Cantara,BiscottiandRaina2007). Inthisregard,keychallenges lienotonly inthecorrect design and execution of business processes or the integration ofheterogeneous systems and identities, but also in providing an adequate userinterface (Hill, Sinur, Flint et al. 2006). The efficiency and effectiveness of humantasksandthusoftheoverallbusinessprocessisstronglyinfluencedbythequalityofsuchauserinterface(Nielsen2005;Wroblewski2008).

To this end, Webbased Enterprise Portals serving as uniform and integratedinterfacestocontent,businessapplicationsandprocesseshaveprovedtobeanidealfoundationofahighperformanceworkplace(Gootzit,Phifer,Valdesetal.2008).Dependingonthescenario,theyservediversetargetaudiencesincludingemployees,customersandbusinesspartners.Byprovidingapersonalizedoverviewofavailableandrunningbusinessprocessesaswellashighqualityuserinterfacesforcompletingassociatedtasks,theypromisetoempoweruserstodirectlycontributetobusinessprocessesinanefficientandeffectiveway.Severalstudiesunderlinethecurrentand

2 Chapter1Introduction

future importanceofEnterprisePortals to companiesas they rankamong the topfivespendingprioritiesofCIOs(MerrillLynch2006;Alter2007).Forresterfoundoutina recent studyamongcompanies inEurope,MiddleEastandAfrica, thatnearlyevery tenth of the surveyed companies is planning to establish a new EnterprisePortal(Lucas,Adrian,Wangetal.2007).TheworldwidemarketforEnterprisePortalsisestimatedtogrowapproximatelyninepercentannuallyforthenextseveralyears(Cantara,BiscottiandRaina2007).Thesignificantattentionassignedtothisfieldcanbeparticularlyattributedtothestrongneedfor integratingbusinessprocessesandheterogeneous application landscapes as well as exposing them to larger andexternalaudiences(BEASystems2007).

From the technical point of view, such portals represent a unique genre ofWebbasedapplicationsnamedWorkflowbasedWebApplications(Kappel,Prll,Reichetal.2006).Whilenaturallyplacinghighdemandsregardingworkflowexecution,richuser interactionandWebservice integration,theyalsosharespecialcharacteristicsinherent to Webbased applications in contrast to conventional applications(Freudenstein,Buck,Nussbaumeretal.2007).Thesecomprise,amongothers, fastevolutioncycles,anincreasedimportanceofusabilityandaestheticaspects,agreatvarietyofuserinterfacesincludingmobiledevices,shorterdevelopmenttimeframes,strongsignificanceofstandards,difficultiesinachievingeffectivereuse,andagreatvarietyofinvolvedstakeholders(Deshpande,Murugesan,Ginigeetal.2002;Mendesand Mosley 2006). Facing the immense complexity resulting from thesecharacteristics, a dedicated engineering approach providingmodels, systems andmethodologiesforthisnewclassofworkflowbasedWebapplicationsisrequired.

Besidestheuniquecharacteristicsandchallengesmentionedabove,onekeyfactorarising from a communication and collaboration perspective deserves particularattention: strong stakeholder involvement. Evaluations on reasons of softwareproject failures highlight that factors like stakeholder involvement andcommunicationaswellasclearbusinessobjectivesarecrucialforaprojectssuccess(The Standish Group International 19942008; Charette 2005). This holds trueparticularly in the context of workflowbased Web applications. As they areconstructed according to business processes, which naturally encompass a greatvariety of stakeholders, efficient and effective communications among allparticipants including the development team are vital. Consequently, a suitableengineeringapproachshouldprovidededicatedconcepts,methodologiesandtoolsinordertoestablishsuccessfulstakeholdercollaboration.

1.1 ResearchQuestionsandContributions

In the following, the research questions addressed by this thesis as well as itscorrespondingcontributionsarepresented.Whilethissectionisonlyintendedasanoverview,adetailedanalysisoftheproblemdomainisconductedinChapter2.

Themainquestionthatdrovetheresearchpresentedinthisdissertationis:

1.1ResearchQuestionsandContributions 3

Main Question: How can workflowbased Web applications beconstructed in close collaborationwith stakeholders in an efficient andeffectiveway?

In this context, efficiency addresses the dimension of time which is of interestregarding various aspects like duration of development cycles, preparation orlearning times for involved stakeholders or the required time span for adoptingchanges. On the other hand, effectiveness concerns the qualitative dimensionfocusing on aspects like compliancewith stakeholder requirements, reducing thepotential for misunderstandings, the usability of user interfaces or enablingsuccessfulreuseofexistingartifactsbyimprovingsearchquality.

Obviously the above cited main question is rather abstract and covers a verycomprehensiverangeofdistinctresearchareasandproblems.Inordertoconveyanoverviewoftheproblemscopeaddressedbythisthesis,itwillberefinedintoseveralmore specific questions. Each of these questions addresses a particular researchproblemeitherrelatedtouniquecharacteristicsofworkflowbasedWebapplicationsthemselvesortheassociateddevelopmentandevolutionprocess.

ThefirstquestionconcernstheconstructionandevolutionofworkflowbasedWebapplications:

Research Question Q1: How can Web applications supporting thedistributed execution of longrunning workflows by controlling theprocess flow and providing adequate user interfaces be efficientlyconstructedandevolved?

Thiscomprisesseveralaspectsrangingfromadedicatedengineeringmethodologytoan adequate architecturemodel.Moreover, it covers the efficientmodeling anddevelopmentofcomponentscontrolling,persisting,andmanagingtheprocessflowas well as the way of linking it to corresponding actions and Webbased userinterfaces. Beyond that, natural characteristics ofWebbased solutions like shortevolution cycles, platform and deviceindependency and their high degree ofdistributionhavetobeaddressed.

To this end, a novel engineering methodology, the Workflow DSL approach,combiningmodeldrivenwith componentbased software engineering concepts ispresented (Freudenstein, Buck, Nussbaumer et al. 2007). It is founded on astandardsbased DomainSpecific Language (DSL) for the continuous and iterativemodelingofworkflowbasedWebapplications.TheDSLsmodelingnotationsallowfor specifying the process flow and formapping process activities to a catalog oflogicalWebspecificActivityBuildingBlocks,e.g.Web service communication, richdialog interaction (cf. Research Question Q2) or data presentation (Freudenstein,Nussbaumer,Majeretal.2007).Eachofthesebuildingblocks isagainrealizedasaDSL requiringonlyaminimalconfiguration set, therebycomplementing the strongfocusonmodeling insteadofprogrammingandallowing forrapidevolutioncycles.The architecturalmodelof the resulting applications is fully serviceoriented, thussupporting federative scenarios. In conclusion, theWorkflowDSL approach allows

4 Chapter1Introduction

fortheefficientconstructionandevolutionofdistributedandplatformindependentworkflowbasedWebapplicationsonapuremodelbasis.

The second question addresses the important aspect of a workflowbased Webapplications user interface which mainly consists of complex Webbased Dialogcomponents:

Research Question Q2: How can complex Webbased dialogs beefficientlyconstructedandevolvedusingamethodology that inherentlyaddressesthesedialogshighdemandsonusabilityaspects?

Forendusers,advanceddialogsrepresentthemainmeansforworkinthecontextofworkflowbasedWebapplications.Correspondingtothecomplexityofthetasktheyaredesignedfor,theyareusuallybasedonrathercomprehensivedatamodelswithcomplex internal dependencies. As they often replace forms thatwere originallypaperbased,most of todays dialog engineering approaches and tools suggest adesignmethodologysimilartothoseforpaperbasedforms.Asaconsequence,boththe potentials and the special requirements of dialogs in the Web are oftenneglected.This in turn results incognitiveoverload, lowusabilityandultimately inpoortaskandprocessperformance.

ThemodeldrivenDialogDSLapproachpresentedinthisthesisprovidesamodelingnotation, a technical support system and an engineering methodology thatinherently address these challenges (Freudenstein and Nussbaumer 2008a;Freudenstein, Nussbaumer, Allerding et al. 2008). Thereby, complex deviceindependent dialogs with rich behavior and appearance can be efficientlyconstructed and evolved. The empirical evaluation of the Dialog DSL approachshowedthatadvanceddialogscanbeconstructedandevolved inconsiderably lesstime compared to todaysWeb development frameworks. In the experiment, theparticipantshadnopreviousknowledgeabouttheDialogDSLapproach,itsnotationand editor. Even stakeholders without any technical background were able tosuccessfullyemploytheapproach.

The thirdquestion refers to theproblemdomainof reuse in theWebEngineeringdiscipline in general and regarding the construction of workflowbased Webapplicationsinparticular:

ResearchQuestionQ3:Howcaneffectivereuseacrossthewiderangeofheterogeneous artifacts and methodologies in the Web Engineeringdomainberealized?

Particularly model and componentbased engineering approaches like thosepresented in this thesiscanbenefitconsiderably fromanadequate reuse support,thus improving, amongst others, development efficiency and software quality.However,theefficientrealizationofreuseshouldnotbeconsideredexclusivelyfortheproblemdomainofworkflowbasedWebapplicationsorevenonlyaparticularengineeringmethodology.Infact,tofullyutilizethegreatpotentialsofreuse,amoreholisticperspective,spanningallkindsofartifactsandunifyingtheexistingvarietyofheterogeneousWebEngineeringmethodologiesisrequired.

1.1ResearchQuestionsandContributions 5

Facingthesechallenges,theWebEngineeringReuseSphereapproachfacilitatestheefficient and effective reuse across todays Web Engineering methodologies(Freudenstein, Boettger and Nussbaumer 2008). A welldefined ontology for theWebEngineeringdomainformsitscoreandallowsforinnovativeandholisticsearchstrategies.Tounfold the fullpotentialof reuse, theapproachcoversbothplannedand spontaneous reuse, thereby extending reuse to the complete lifecycle of anartifact.Moreover, the approach represents an important contribution to currentconsolidation activities in theWeb Engineering research community. On the onehand,itsontologyoftheWebEngineeringdomainenablestheunificationofdiversemethodologies on a conceptual level.On the other hand, it establishes a sharedfoundationforrealcrossmethodologicalreuse.

The fourthquestion focusesonthestrong involvementofstakeholdersthroughouttheprocessofconstructinganddevelopingworkflowbasedWebapplications.Thus,itrepresentsacrosscuttingconcernaffectingallofthepresentedresearchquestionsandcontributions.

Research Question Q4: How can models and methodologies in thecontext of workflowbased Web applications be designed stakeholderoriented, thus allowing for continuous, intensified and much moreeffectivestakeholdercollaboration?

As already mentioned in the previous section, the strong involvement ofstakeholders throughout all phases of the development process is crucial for aprojectssuccess.ThisholdstrueparticularlyfortheconstructionofworkflowbasedWeb applications as the great variety of future endusers knows the concernedbusiness processes and the tasks performed therein best. Thus, enablingstakeholderstocontributeactivelyorevenautonomouslytothedevelopmenteffortby understanding, validating and specifying parts of the solution being built, isdesirable.

Againstthisbackground,anewstakeholderorienteddevelopmentapproach,namedDSLbased Web Engineering (Nussbaumer, Freudenstein and Gaedke 2006c), ispresented. It isbasedonthe ideaofemployingdistinctDomainSpecificLanguages(DSLs)forthemodeldrivenspecificationofaWebapplicationsvariousaspects,witheachDSLbeinghighlyfocusedonaparticularproblemdomain.ExistingmodeldrivenWebEngineeringmethodologiesareusuallydeveloperorientedandprovideratherheavyweightandcomplexmodelingapproaches.ADSL,however, isdesigned inastakeholderorientedwaywith strong emphasis on simplicity and employingwellknown concepts, abstractions and notations from the problem domain. Byincorporating various graphicalnotations and accompanyingeditors, aDSL canbetailored to the characteristics and requirements of individual stakeholder groups(Nussbaumer,FreudensteinandGaedke2006a).Thus,DSLsareeasytounderstand,learn anduseboth fordevelopers and stakeholders (Nussbaumer, FreudensteinandGaedke2006b).EachDSLprovidesadedicatedsoftwarecomponentbeingableto interpretthemodelsdevelopedwithaDSLatruntime.Hence,Webapplicationscan be rapidly constructed and evolved by composing DSLspecific softwarecomponents and configuring them with DSL programs in terms of models. The

6 Chapter1Introduction

immediate availability of a running application based on a model presents anadditionalcontributiontotheeffectivecollaborationwithstakeholders.

TheDSLbasedengineeringapproach forms the foundation forallmodels, systemsand methodologies related to the three research questions stated above, thusdeeplyintegratingstakeholderorientationintoeachofthem.

Consequently,theWorkflowDSLapproach,forexample,allowsthemultinotationalmodeling of workflows with an extensible set of established and standardizedmodeling notations and tools. These include, for example, the Business ProcessModelingNotation (BPMN)usingMicrosoftVisio,UMLActivityDiagramsdesignedwith IBMRationalSoftwareDeveloper,PetriNetsemploying INCOME2010orevensimple task lists created with Microsoft Word. Thus, stakeholders can specifyworkflowbasedWebapplicationsbyusing theirown languages, i.e. thenotationsandtoolstheyknowbest.

RegardingtheDialogDSLapproach,stakeholderorientationisexpressedintermsofa very simple and intuitive modeling notation for highly dynamic and complexdialogs,asupplementaleasytouseeditorandanengineeringmethodologyenablingrapidevolutioncycles.Asaresult,stakeholderscanparticipate inandcontributetothe development effort much more intensively than with traditional engineeringapproaches.

The Web Engineering Reuse Sphere finally closes the gap between the set ofavailableDSLsand reusableartifactson theone side,and stakeholders inneedofperformingdevelopment taskson theother side. Therefore, itprovides advancedontologybasedsearchfacilitieswhichduetotheirsimplicityenablestakeholderstosearchautonomously foradequateresolutionstrategies (e.g.aDSL)andrelatedartifacts for a given development task. In contrast to existing reuse approaches,stakeholders can thus find appropriate DSLs, modeling notations and reusableartifacts not only according to conventional search dimensions like the givenproblem domain or keywords but also corresponding to their individual skills andknowledge.

In conclusion, the solutions presented in this thesis represent a significantadvancement for the efficient and effective construction ofworkflowbasedWebapplications with stakeholders. They have been successfully implemented andevaluatedindifferentscenariosincludingbothformalexperimentalevaluationsandrealworld applications, for example in the context of the project KarlsruhesIntegratedInformationManagement(KIM)(Juling2005).Ineithercase,substantialimprovementsintermsofefficiencyandeffectivenessthroughoutthedevelopmentprocesswere observed. Furthermore, large parts of this thesiswere published innumerous papers at international conferences, workshops and journals andintensely discussed with researches from the Web Engineering discipline andadjacentresearchareas.

1.2ResearchContextandScope 7

1.2 ResearchContextandScope

Workflowbased Web applications are mature and complex software systems,representing an own class ofWeb applications. LikeWeb applications in general,theyusetheWorldWideWeb, i.e. itstechnologies,standardsandparadigms,bothas a development platform and as a user platform, leading to the followingdefinition:

Definition 1.1: A Web application is a software system based ontechnologiesand standardsof theWorldWideWebConsortium (W3C)that provides Webspecific resources such as content and servicesthrough a user interface, theWeb browser. (Kappel, Prll, Reich et al.2006)

Compared to traditional software applications, the unique characteristics ofWebapplications require dedicated approaches, methodologies, tools, techniques andguidelines (Ginige and Murugesan 2001). This particularly affects differencesregarding the people involved in the development process, the intrinsiccharacteristicsofWebapplicationsandtheaudienceforwhichtheyaredeveloped.TheWebEngineeringresearchdisciplineaddressestheseneeds:

Definition1.2:WebEngineering is theestablishmentanduseof soundscientific, engineering and management principles and disciplined andsystematic approaches to the successful development, deployment andmaintenance of high quality Webbased systems and applications.(Murugesan,Deshpande,Hansenetal.1999)

While Web Engineering adopts and encompasses numerous principles andmethodologies from the software engineering domain, there aremany significantdifferencesposingadditionalchallengesandthereforerequiringnovelWebspecificapproaches (Kappel, Prll, Reich et al. 2006). Beyond that,Web Engineering is amuch more multidisciplinary field and encompasses contributions from distinctdisciplines such as hypermedia engineering, requirements engineering, usabilityengineering,informationengineering,graphicsdesign,networkmanagement,andofcourse software engineering (Deshpande,Murugesan,Ginige et al. 2002;MendesandMosley2006).

Consideringtheresearchquestionsgiven intheprevioussection,thisthesisclearlyrepresentsa contribution to theWebEngineering researchdiscipline. Itpromotesthedisciplinescurrentstateof theartbynovelapproaches,models,systems,andmethodologiesfortheinvestigatedproblemdomains.Mostofthemwerepresentedanddiscussedwith researchers from theWeb Engineeringdiscipline and adjacentresearch fields on international conferences, e.g. the International Conference onWeb Engineering (ICWE) 20062008 or theWorldWideWeb Conference (WWW)20062008.

Due to its focus onWeb applications supporting the execution ofworkflows, thediscipline of Business ProcessManagement (BPM) seems to be very close to this

8 Chapter1Introduction

thesis.Asdefined in(vanderAalst,terHofstedeandWeske2003),BPMcoversthesupportofbusinessprocessesusingmethods, techniques,and software todesign,enact,control,andanalyzeoperationalprocesses involvinghumans,organizations,applications,documentsandothersourcesof information.Certainly,someaspectsof this thesis overlapwith this area, e.g. the homogenization of diverse businessprocessmodelingnotations inorder toallow formultinotationalmodelingor theefficienttransformationofprocessmodelsintosoftwarecomponents.However,thisthesisconsiders itselfmainlyfocusedonWebspecificresearchquestionsrelatedtotheWebapplication itselfand itsuser interfaceaswellasmethodologies for theirefficientdevelopmentandevolution.

1.3 ThesisStructure

An overview of the structure of this thesis is given in Figure 11. Following thisintroduction, inChapter2,adetailedanalysisofthethesisproblemdomainbasedonexamplescenariosfromrealworldprojects isperformed.Thereby,auniversallyvalid set of welldefined requirements for an adequate solution is elaborated.Chapter 3 presents existing scientific and commercial approaches related to thegiven problem scope. Each of these approaches is evaluated against therequirements catalog defined in the preceding chapter, thus highlighting theirbenefitsanddrawbacksforthisthesisproblemscopeandultimatelyunderliningtheneedfornovel,innovativeapproachesandmethodologies.

Thesubsequent fivechapterscontain themaincontributionsof this thesis.Firstofall,Chapter4givesanoverviewoftheoverallsolutionpresentedinthisthesisaswellas itscorepillarsandtheir interrelations.This includesthe introductionoftheDSLbased Web Engineering framework which represents a key foundation for thefollowing two chapters. Based on this overview, each of the solution elements ispresentedinaseparatechapter.

Chapter5introducestheWorkflowDSLapproachforthemodeldrivenconstructionofworkflowbasedWebApplicationswithstakeholders.InChapter6,theDialogDSLapproach covering the modeldriven and stakeholderoriented engineering ofadvancedWebbaseddialogswhetherasintegralcomponentsofaworkflowbasedWebapplicationorasstandalonemeansofuserinteractionispresented.TheWebEngineeringReuseSphere,aholisticandstakeholderorientedapproachforeffectivereuse in theWeb Engineering domain in general and in the context ofworkflowbasedWebapplicationsinparticular,isdescribedinChapter7.

Chapter8addressestheevaluationofthepresentedsolutionsbasedonrealworldscenarios and formal empirical studies and experiments. Finally, Chapter 9summarizes the contributions and results of this thesis and gives an outlook onfutureresearchdirections.

1.3ThesisStructure 9

Figure11:StructureoftheThesis

2 ProblemScope

As adumbrated by the research questions in Section 1.1, the problem domaincoveredbythisthesiscomprisesvariousaspects.Fromatechnologicalperspective,workflowbasedWebapplications imposeagreatvarietyofchallenges,particularlyconcerningdimensionslikeworkflowdesignandexecution,applicationconstructionandevolution,user interfaces and reuse.On theotherhand, significantproblemsconcerning theefficientandeffective involvementof stakeholders throughout thedevelopmentprocessarisefromacommunicationandcollaborationperspective.Astheyaredeeply interrelatedwithallother,moretechnologicalandmethodologicalaspects,theyformacrosscuttingrequirementdimension.

Inthischapter,asystematicanddetailedanalysisoftheproblemscopeaddressedbythis thesis will be performed. After a short introduction of general challengesregardingstakeholdercollaboration intheWebEngineeringdomain,theanalysis issplitintothreeproblemareas,wherebythestronginvolvementofstakeholdersasacrosscuttingconcern isexaminedfromaholisticviewpointforeachoftheseareas.Throughoutthischapter,illustrativerealworldscenariosareintroducedandserveasrunningexamplesthroughoutthisthesis.Eachsectionconcludeswithasummarizingrequirementscatalogwhichformsthefoundationfortheassessmentofthecurrentstateoftheartaswellasthedesignandevaluationofthepresentedcontributions.

2.1 StakeholderCollaborationintheWebEngineeringField

In the development of complex Webbased solutions, challenges in thecommunication and collaboration between all involved stakeholders make up asecond major problem area besides technical problems and requirements(Nussbaumer, Freudenstein andGaedke2006a).Compared to traditional softwaredevelopmentprojects,both the amount and theheterogeneityof stakeholders inWeb applicationdevelopmentprojects are significantlyhigher (Escalona andKoch2004). In themost cases, stakeholdersbelong to completelydiversedepartments,havedifferentprofessionalandeducationalbackgroundsandpossessvarious skillsand knowledge. Consequently, each group uses its own languagewhen talkingabout aspects of the solution to be built. This becomes obvious especially in the

12 Chapter2ProblemScope

phases related to requirements management and conceptual design whenunderstanding the various languagesof theparticular stakeholders isdecisiveandmisunderstandingsmustbeavoidedas faraspossible.Agreeingonand learningacommon languageasapotentialsolution to this, isusuallynot feasiblebecauseofthestakeholdersverylimitedavailability.

Over the last years, a lot of languages andmodeling approaches for the (mostlymodelbased) specification of distributed Webbased solutions have beenestablished(cf.Chapter3).Mostofthemattempttocovertheirproblemdomainasexhaustive as possible and therefore include concepts and notations for almostevery aspect of the problem domain. This often leads to very expressive andpowerfulmodeling languages,beingagoodmeansofconceptualand logicaldesignwithin the developer team. However, regarding the communication andcollaborationwith stakeholders, these heavyweight approaches are too complexandthusnotappropriate.Forstakeholdersbeingpredominantlynonprogrammers,itwouldcosttoomuchtimeandefforttolearntheseextensivemodelinglanguagesandnotations.

Thecrucial influenceofstrongstakeholder involvementonaprojectssuccesswasproved in comprehensive studies (The Standish Group International 19942008;Charette 2005) and taken on in agile software development methods (Cockburn2006).Thus,also theWebEngineeringdisciplineneedsmore stakeholderorientedapproaches intensifying the collaboration and supporting efficient and effectivecommunication throughout all phases of the development process (Nussbaumer,Freudenstein andGaedke 2006c). The vision should be to provide languages andnotationstailoredtothecharacteristicsandneedsof individualstakeholdergroupsand thus enabling them to directly contribute to the development effort byunderstanding, validating, and even autonomously specifying aspects of a Webbasedsolution.

2.2 WorkflowbasedWebApplications

Overthelastdecades,thenatureofacompanysbusinessprocessesaswellasitsITlandscape has transformed tremendously. Whereas previously competitiveadvantage was often considered from a productoriented perspective,differentiation inaserviceorientedworld liketoday ispredominantlybasedontheuniqueness of services and business processes (Heskett, Sasser and Schlesinger1997).Likewise,theIT landscapehasevolvedsignificantlyfromarathercentralizedandhomogeneoustoahighlydistributedandheterogeneousstructure(Bieberstein,Bose,Fiammanteetal.2006).

Consequently,businessprocessestodayaremorecomplex,theyspanagreatvarietyof roles, organizational units and even companies, they suffer from mediadiscontinuity issues, and they involve diverse heterogeneous and distributed ITsystemsandapplications.Moreover,agilityintermsoftheflexibilitytorapidlymeetchangedornewbusinessdemands representsoneof themostvaluableassets for

2.2WorkflowbasedWebApplications 13

companies.Whereasinthepast,businessprocesseschangedonceayear,theynowchange once a month or sometimes even once a week (Carter 2007). As aconsequence,businessprocessperformanceoftenturnsouttoberatherpooranderrorprone.

To this end, companies started to adopt business processmanagement suites forrealizing integrated and controlled endtoend business processes. Such systemsallow for modeling, controlling and monitoring business processes in form ofworkflowsacrossdiverse roles,organizationsand IT systems.ProminentexamplesincludetheIBMWebSphereSuite,theOracleBPMSuite,ortheSAPNetWeaverBPMSuite.

Asindicatedbytheprevioussentence,thereisaclearseparationbetweenthetermsbusinessprocessandworkflow,eventhoughtheyareoftenusedassynonyms.The Workflow Management Coalition (WfMC) defines these terms as follows(WorkflowManagementCoalition1997):

Definition2.1BusinessProcess:Asetofoneormorelinkedproceduresoractivitieswhichcollectivelyrealizeabusinessobjectiveorpolicygoal,normally within the context of an organizational structure definingfunctionalrolesandrelationships.

Definition 2.2 Workflow: The automation of a business process, inwholeorpart,duringwhichdocuments, informationortasksarepassedfrom one participant to another for action, according to a set ofproceduralrules.

Hence, the main difference between these terms lies in the fact that the termworkflow emphasizes the aspect of softwarebased enactment of a businessprocesswhichissupportedbyaworkflowmanagementsystem.

GartnerResearchpredictsthat,by2009,20%ofbusinessprocessesofGlobal2000companieswillbe supportedbyworkflowmanagement systems.Unlikeprevailingsystem and applicationoriented processes without human interaction, theseprocesseswill predominately involve a considerable amount of humanwork thatdifferentiate the company from its competitors and that is poorly supported byestablished IT systems (Hill, Sinur, Flint et al. 2006). This growing importance ofhuman tasks within workflows leads to the question of adequate user interfaceconceptsanddedicatedmethodologicalsolutions.

To thisend,Webbasedapplicationsandportalsasuniformand integratedaccesschannels for initiating and interacting with such workflows have recently gainedsignificant attention (Gootzit, Phifer, Valdes et al. 2008). Based on the WfMCdefinition for workflow application, i.e. software programs that interactwith aworkflow enactment service and handle [] the processing required to support aparticular activity or activities (Workflow Management Coalition 1997), andconsidering that theyareWebapplications in thesenseofDefinition1.1, theyaretermedWorkflowbasedWebApplications.As such, theycombine thepotentialsandbenefitsofbothfields.

14 Chapter2ProblemScope

Consequently, the main benefits which can be realized by workflowbased Webapplicationsprovided that theycanbe implemented inanefficientandeffectiveway comprise(PuschmannandAlt2004;Phifer2006;BEASystems2007;Gootzit,Phifer,Valdesetal.2008):

increasedefficiencyandqualityofbusinessprocessesandindividualtasks integratedprovisionofpreviouslysiloedapplications,systemsandprocesses consistentandimproveduserexperience replacementofmultipleapplicationspecificuserinterfacesandaccounts ubiquitousaccessandavailability reductionofpaperbasedormanualprocesses reducedmaintenanceefforts increasedbusinessflexibility

Depending on the business processes they support, workflowbased Webapplicationscanserveagreatvarietyoftargetaudiences.These includeemployeesinaBusinesstoEmployee (B2E)context (oftenreferredtoasEnterprisePortals),customersinBusinesstoConsumer(B2C)portalsaswellasbusinesspartnerswithinBusinesstoBusiness(B2B)Websites.

Thesegreatpotentialsandexpectations towardsworkflowbasedWebapplicationscomealongwithasignificant,multifacetedcomplexityregardingtheirconstructionand evolution. In the following subsection, specific challenges arising from atechnicalperspectivewillbeanalyzed,whereasSection2.2.2examineschallengesinthe contextof collaboratingand communicatingwith stakeholders throughout thedevelopmentprocess.

2.2.1 TechnicalChallenges

In the following, the specific technical challenges arising in the construction andevolution of workflowbased Web applications will be elaborated based on anexamplescenario.ThescenariodealswithaworkflowbasedWebapplicationforthehandling of an exemplary business trip process which could be found in acompanys intranet.Thescenarioand itscharacteristicswerechosen inaway thatensures the universal validity of the resulting challenges and requirements anadequatesolutionshouldaddress.

Figure21showsasimplifiedexcerptfromthecurrentbusinesstripprocessattheKarlsruheInstituteofTechnology(KIT)focusingonthereimbursementprocessafterthe employee has returned from the trip. In this context, a variety of roles anddepartments fromallover theuniversity is involved,e.g. theemployee, the traveldepartment, the travelers institute director or manager and the accountsdepartment. In earlierphases of the business process, also externalorganizationslikepartnertravelagenciescouldbeincluded.Theexamplestartswiththeemployeecreatingatravelexpensereport,which iscurrentlydoneusingapaperbasedform(Karlsruhe Instituteof Technology 2009).Next, the filled form is sentper internal

2.2WorkflowbasedWebApplications 15

mail to the traveldepartment,whichprocesses it,createsa refundstatementandsends itbacktotheemployeeviainternalmail(potentialfollowupinquiriesbythetravel department and associated replies by the employee were left out in thisexample).Next,theemployeecheckstherefundstatementandcouldpossiblyhaveobjections. In this case, anobjectionhandling process, againpaperbased and viainternal mail, follows. Afterwards, the employees institute director or managerreceivesapayment statement inorder toapprove it (the subprocess incaseofarejection was left out in this example). Subsequently, the accounts departmentprocessesthepaymentandtheemployeereceivesapaymentnotification.

Figure21:SimplifiedExcerptfromtheBusinessTripBusinessProcess

Amajor technical challenge in the contextof thedevelopmentofworkflowbasedWebapplicationsliesinthetechnicalimplementationofthebusinessprocesstoberealized.Thiscomprisestheconstructionofaworkflowcomponentaccordingtothegivenbusinessprocessmodeloranenhancedworkflowmodelrespectively.Suchacomponent should allow for instantiating new workflow instances as well ascontrollingandensuringtheexactprocessflowandthecorrectdistributionoftaskstoroles.Moreover,withrespectto longrunningworkflowswithpossibly longtimespans between activities, itmust be capable ofmaking the current state of theworkflowpersistentandresumingatalaterpointintime.Inaddition,theworkflowcomponent is in charge of responding to queries about the current status of aworkflow instanceor theavailable tasks foragivenuseraswellas supplyingandreceivingdataobjectsasinputoroutputparametersoftasks.

Theimplementationofsuchaworkflowcomponentcanbesupportedbyaworkflowengine, e.g.MicrosoftWindowsWorkflow Foundation (Microsoft Corp. 2006c) orIBMWebSphereMQWorkflow (IBM2006);however,asignificantamountofworkand complexity remains for constructing a workflow program as input for theworkflowengineaswellasintegrationchallengesregardingtheWebapplicationasawholeanditsuserinterfaceinparticularbothfortheenactmentofhumantasksaswellasforconsuminginfrastructureservicesprovidedbytheengine.

Analyzingtheparticulartasksofthebusinesstripexampleprocessabove,variousactivity types to be supported by a workflowbased Web application can beidentified.Agreatmajorityoftasks,e.g.CreateExpenseReport,ProcessExpense

16 Chapter2ProblemScope

ReportorCheckRefundStatement,requiresrichdialogbasedhumaninteraction(cf.Section2.3).Othersconsistofpresentingdatatoauser,e.g.ReceivePaymentNotification.Sometasks,e.g.ProcessPayment,relyondatatoberetrievedfromor stored in heterogeneous backend systems or even services from externalproviders.SuchscenariosareusuallyrealizedviaWebservicecommunications,whichcanoccureither in thecontextofautonomous systemactivitiesor incombinationwith thementioned activity types. In advancedworkflow scenarios, e.g. in supplychainmanagement,therecouldalsobephysicalactivitieslikeshippingapackageorhavinganinpersonmeeting.Inordertorealizeanendtoendsupportforbusinessprocesses, these tasks need also to be considered and realized as some kind ofcompletionconfirmationdialog.

Besidessuch tasksrequiringonlyacompletionconfirmation, thereare taskswhichalsotakeplaceoutdoorsoratleastawayfromadesktopornotebookcomputerandwhich could be better supported by one of the aforementioned activity types. Insuchcases,processparticipants shouldbeable tocollaborateusingotherdevices,e.g. PDAs or smart phones. This raises the requirement for mobile and deviceindependent access, which is a common, primarily user interfacerelated,requirement for advancedWebbased applications (WorldWideWeb Consortium2007).

Beyond that, some tasksaremoreefficientlyconducted indedicated, taskspecificclientapplications,e.g.aspreadsheetapplication(Kotoric2007).Thus,eventhoughtryingtoofferoneintegrated,browserbaseduserinterfaceisadesirableobjective,aworkflowbasedWebapplication shouldalso supply the technical foundation forcompleting tasksoff thebrowser.Thus, thearchitecturalmodelof theapplicationshouldbedesignedinawaythatallowsforadditionalworkflowinteractionchannelsbesidestheWebbaseduserinterface.

ThisrepresentsalsoacrucialrequirementforworkflowbasedWebapplicationsinaB2Bcontextastheyspannotonlydiverseorganizationalrolesanddepartments,butalsomultiplecompanies.ThefactthattheworkflowapplicationisaWebapplicationalreadyentails thepotential tomake itavailable toaglobalaudience.Sometimes,however, in such scenarios,externalorganizationsprefer tohave theiremployeesparticipateintheworkflowfromwithintheirownportalapplications.Inthisrespect,apart from federationrelated security challenges (Menzel, Thomas,Wolter et al.2007), theseexternalportalapplicationscanbeconsidered likenonbrowserclientapplicationsasdescribedbefore.

For the technical realizationofabusinessprocessparticular tasksbyaworkflowbasedWebapplication,anadequateapproachshouldprovideactivitybuildingblocksfortheaforementionedhumanandsystemorientedactivitytypes.Inaddition,theworkflowbasedWeb applicationsarchitecturemodel aswell as its user interfaceshouldbepreparedforaccessusingmobiledevicesaswellas internalandexternalclient applications. The demand for a workflowbased Web applications fullcoverage of all occurring taskswithin a business process holds great benefits intermsofprocessefficiencyandqualityaswellassolvingmediadiscontinuityissues,but also reveals a great amount of development effort and technical complexity

2.2WorkflowbasedWebApplications 17

which in turn underlines the necessity of adequate models, systems andmethodologies.

A further problem area concerns the aspects of agility and evolution. WebapplicationsingeneralandworkflowbasedWebapplicationsinparticularunderlieacontinuous evolution due to frequent changes (Roger S. Pressman 2005), e.g.adjustments in the business process structure, integration of new partners orchanges indialogsorpresentationdesign.Forexample, inthepresentedbusinesstripscenario,varioustypesofchangesandextensionslikechangedresponsibilities,integration of new travel agencies or external partner services, modifications tobusiness rules,extensions to formsor the integrationofnewbackendsystemsareimaginable, particularly in the context of the currentmerger of theUniversity ofKarlsruhe(TH)andtheForschungszentrumKarlsruhetowardstheKarlsruheInstituteof Technology (KIT) (Karlsruhe Institute of Technology 2007). Furthermore,compared to traditional software projects, the development timeframes of Webapplicationsareinmostcasessignificantlyshorter(McDonaldandWelland2001).

Thus,agilityintermsofsupportingshortrevisionlifecyclesandtheefficientadoptionof such changes is essential. To this end, a modeldriven software developmentapproachseemstobeapromisingoptionasitallowsforcomparativelyeasychangesin themodelswhich then need to be ideally automatically propagated to theactual implementation (Stahl and Vlter 2006). However, achieving a continuousmodelbasedapproachthroughoutallphasesofthedevelopmentprocessaswellasassuringconsistencybetweenthevariousmodelsandtheimplementationrepresentchallengingrequirements.

WithrespecttothegreatdiversityofartifactsproducedduringthedevelopmentandevolutionofWebapplicationsandparticularlyworkflowbasedWebapplicationsaswell as facing requirements like strong support for agility and evolution,developmentefficiencyandsoftwarequality,effectivereusestrategiesbecomeakeyfactor.Ontheonehand,anadequateapproachfortheconstructionandevolutionofworkflowbasedWebapplicationsshouldexplorethepotentialsofcomponentbasedsoftwareengineering (Sommerville2007b).Ananalysisof thevarious task typesasoutlinedabovecould representastartingpoint for thedefinitionofhighlygenericand reusable software components for the implementationofworkflow tasks.Onthe other hand, the systematic reuse of all kinds of artifacts throughout thedevelopmentprocessshouldbeexamined(cf.Section2.4).

2.2.2 StakeholderCollaborationforWorkflowbasedWebApplications

Considering the construction and evolution of workflowbased Web applications,particular challenges regarding the efficient and effective collaboration withstakeholdersarise.Duringthespecificationoftheenvisionedsolution,amultitudeofstakeholdershastobeinvolved.Forthepresentedexampleprocessexcerpt,oneormorerepresentatives fromeachoftheparticipatingroles, i.e.travelingemployees,thetraveldepartment, institutedirectorsandtheaccountsdepartment,havetobe

18 Chapter2ProblemScope

included.As theexample showsa smallpartof theprocessonly, theamountandheterogeneityofconcernedstakeholdersaremuchhigherforthecompletebusinessprocess.Theeffectivecommunicationwiththesegroupsiscrucial,astheyknowthebusinessprocessbestand,unlikeothertypesofWebapplications,thereisveryfewroomforspecificationsbasedonassumptions.

ThespecificationprocessforworkflowbasedWebapplicationscanbedifferentiatedintobusinessprocessmodelingandworkflowmodeling.Theformerfocusesontheunderlyingbusinessprocess,itsstructureandexactcontrolflow,whereasthelatteraddressesitstechnicalrealizationbytheworkflowbasedWebapplication.

During business process analysis and specification, business process modelsrepresentthemaindesignartifactanddifferentstakeholderscontributetodifferentsectionsof theprocess.A firststep in the requirementsanalysisusually lies in theelicitationoftasksandcorrespondingrolesoftheconsideredsection.Accordingtothe presented example scenario, Table 21 shows a result of this early elicitationactivityinformofausuallypenandpaperbasedtable.

Table21:TablebasedElicitationofTasksandRolesofaBusinessProcessExcerpt

Task Role

CreateExpenseReport Employee

ProcessExpenseReport TravelDepartment

CheckRefundStatement Employee

CheckObjection TravelDepartment

ApprovePayment InstituteDirector

ReceivePaymentNotification Employee

ProcessPayment AccountsDepartment

Dependingonthebackgroundandskillsoftheinterviewedstakeholder,thiscanbeanimportantprestagetoanalyzingthedetailedprocessflowinordertoreducethecomplexity and to achieve a stepbystep specification process. The tablebasedspecification also abstracts from a concrete business process modeling notation,thus minimizing the stakeholders required prior knowledge. For the succeedingspecification activities, a member of the development team has to transfer thegathered information into a graphicalmodelwhich canbe rather timeconsumingandalreadyleavesroomformistakes.

Thesubsequentspecificationofthebusinessprocessdetailedstructureandcontrolreveals additional problems. To date, there is still no widelyaccepted standardnotationforbusinessprocessmodeling(Hill,Sinur,Flintetal.2006).Thisholdstruealsoforbusinessprocessmanagementsuitesandrelatedtoolswheremanyvendorsstillemployproprietarynotations.However,particularlyinsuchadiversifiedcontext,the adherence to existing standards where possible becomes even moreimportant. Thus, stakeholders might already know or even use a notation andcorrespondingexistingtools,whichisnotthefactforproprietaryapproaches.

2.2WorkflowbasedWebApplications 19

This heterogeneity further aggravates the collaborationwith stakeholders as theyareconfrontedwithdiversenotationsandtoolsfromprojecttoproject.Hence,theirexperiences,knowledgeandskillsinthesefieldsarelikewiseveryheterogeneous.Asa result, when specifying business processes with stakeholders across anorganization, e.g. in the project Karlsruhes Integrated InformationManagement(KIM)(Juling2005),someofthempreferPetrinetsasameansofcommunicationastheyplayamajorroleintheirresearchcontext(Klink,LiandOberweis2008).Others,forexample,favortheBusinessProcessModelingNotation(BPMN)(White2006)ortheUnifiedModeling Language (UML) (ObjectManagementGroup2005b) for thesamereasonorduetopriorprojectexperienceswiththisnotationandrelatedtools.Andpeoplewithoutanypriorexperiencesorwithanontechnicalbackground,e.g.inhumanities and social sciences, often like a notation in natural language better.Figure 22 illustrates these differences by showing the business trip exampleprocess excerpt in four different notations and tools:BPMNwithMicrosoftVisio,PetriNetswithINCOME2010,UMLActivitywithIBMRationalSoftwareArchitectandatextbasednotation(cf.Table21)withMicrosoftWord.

Figure22:VariousBusinessProcessModelingNotationsandTools

Considering the fact thatdifferent stakeholders contribute todifferent sectionsofone business processmodel, agreeing on a common language, notation and toolseemsinevitable.Somebusinessprocessmodelingnotationsappeartosomeextentsimilarforexperiencedprocessanalystsandcanbeclassifiedintoprocessmodelinglanguage families (Recker and Dreiling 2007). However, stakeholders are usuallyratherlowexperiencedandthechallengeofmultinotationalmodelingacrossthese

20 Chapter2ProblemScope

families still remains. This in turn results in high learning efforts and inefficientcommunications,raisestheprobabilityofmisunderstandingsaswellashinderslongtermefficiencygains.Moreover, thepotentialof reusingalreadyexistingbusinessprocessmodels,whichwerecreatede.g.fordocumentationpurposes,issignificantlyconstrainedtomodelsthatwerecreatedwiththesamenotationandthesametools.

A consolidated view of the presented challenges indicates the necessity of astakeholderoriented approach throughout all stages of the business processmodeling phase. Such an approach should support stakeholders in collaborativelyvalidating,modifyingandevencreatingsharedbusinessprocessmodelsbyallowingeachstakeholdertouseherpreferrednotationandtool.Likewise,modelconsistencymustbeperseveredacrossnotations, toolsandprocessphases.An idealapproachshouldnotbe limitedtospecificnotationsortools,butratherprovidewelldefinedextensionpointsandcorrespondingprocesses.

Thesubsequentworkflowspecification focusesonthetechnical implementationofthemodeledbusinessprocessbymeansof aworkflowbasedWeb application. Inthisregard,therealizationofeachtaskinthebusinessprocesshastobeclarifiedanddesignedinclosecollaborationwiththerelevantstakeholdergroups.Besidesahighlevel mapping of tasks to technical activity building blocks like e.g. dialogbasedinteraction,datapresentationorWebservicecommunicationasdescribedinSection2.2.1,adetaileddesignforeachofthesehastobeconducted.Inthecaseofadialogbasedinteraction,forexample,developersandstakeholdershavetocollaborativelyspecifythedetaileddialogdesigninawaywhichassuresamaximumefficiencyandeffectiveness for future users. The strong technical nature of these specificationtasksfurtheraggravatesefficientandeffectivecommunicationsandentailstheriskofmisunderstandings.

Against thisbackground,hiding technical complexitybecomesa key factor.As thebusinessprocessmodelisalreadyknownfromthebusinessprocessmodelingphaseandthusstillservesasareferencepointforstakeholders,itisdesirabletocontinuetouse itasakeyartifactalso intheworkflowdesign.Whileusuallythe logicalandphysicaldesignofaWebbasedsolutionisperformedemployingdeveloperorientedmodeling notations including lots of technical details, a stakeholderorientedapproach should aim atpreserving the stakeholdersbusinessperspective. Thus, itshouldprovideamuchhigherabstraction levelandshould includetechnicaldetailsonlywherenecessary.Forexample,whendesigningthetechnicalimplementationoftasks in a business process, it is desirable that one activity from a businessperspectivecanberealizedbyonetechnicalactivitybuildingblockandhasnottobesplit up into several activities from a system perspective. Thereby, the businessprocessmodels structure can be kept throughout all stages of the developmentprocess, easing the understanding and orientation for stakeholders. Furthermore,thepotentialsofminimizingandhidingasmuchtechnicaldetailsaspossibleshouldbeexploredthoroughly.Byexploitingautomationpotentialsandcomponentbasedconstructionstrategies,astakeholderorientedapproachshouldstrive for reducingtherequiredinitialdesignsettoaminimum.

Tothisend,principlesandtechniquesfromthemodeldrivensoftwaredevelopmentfield can be a possible solution (Hailpern and Tarr 2006). On the one hand,

2.2WorkflowbasedWebApplications 21

stakeholderanddeveloperscancontinuetospecifythedesignbasedonamodelofthe business process throughout all phases of the development process. On theotherhand,models raise the levelofabstractionandareagoodmeans forhidingcomplexity.However,modeldrivensoftwaredevelopmentcanalsoposeadditionalproblems ifnotappliedmaturely.Firstofall,aproblemtermedmodelcodegap,i.e.thesemanticdistancebetweenamodelartifactanditscoderepresentation,hasto be considered (Warmer and Kleppe 2003). This common disparity requiresdeveloperstotransferspecificationsonamodelbasisintoexecutableprogramcode,which leaves room for interpretation and misunderstandings as well as poseschallenges regarding model redundancy and consistency. This also can result inroundtripengineeringproblemsoccurring inthecaseofevolution.Afurthermeansfor supportingefficientandeffective stakeholdercollaborations is theprovisionofevolutionary prototypes of the application from the very beginning of thedevelopmentprocess(Wiegers2003).Forstakeholders,theyrepresentanidealbasisfor clarifying and completing requirements, exploring design alternatives andvisualizingdevelopmentprogress.

Facing these challenges, a stakeholderoriented solution should provide adequatemodeling support for all phases of the development process and all relevantstakeholder groups. At the same time, it should assure model consistency andpreferablyachieveadirect, losslessandcompletemappingofmodels into runningapplicationsandservices.

2.2.3 RequirementsCatalogfortheDimensionWorkflow

The following catalog briefly summarizes the identified requirements for theproblemdimensionWorkflow:

RWF01 Workflow Management and Execution: Workflowbased Webapplications should be capable of managing and executing longrunningworkflowscomprisingdiverseroles.

RWF02 Continuous, Rich Webbased User Interface: Besides therealization of systemoriented process activities, an adequate engineeringapproachshouldsupporttheefficientconstructionofacontinuous,richWebbaseduserinterfaceforallhumanworkflowtasks.

RWF03 Multimodal Participation: In addition to the Webbased userinterface, process participants should be able to collaborate using variousclientdevicesandapplicationsacrossdiverseplatforms.

RWF04FederationEnabledandComponentBasedArchitectureModel:AworkflowbasedWebapplicationsarchitecturalmodelshouldbedesignedwith respect to federative scenarios as well as explore the potentials ofcomponentbased software engineering for realizing workflow activitybuildingblocks.

22 Chapter2ProblemScope

RWF05AgilityandEvolution:Asuitableapproachshouldsupportagilityin terms of short revision lifecycles as well as efficient adoption ofevolutionarychanges.

RWF06 MultiNotational Modeling: Stakeholders should be able tounderstand, validate, modify and create shared business process andworkflow models using various notations and tools at the same time.Extensibilityfornewnotationsandtoolsshouldbeassuredinanoninvasiveway.

RWF07CompleteModelContinuityandConsistency:Modelsshouldbetheprimarymeansofanalysisanddesignaswellasautomatedevelopmentthroughout all phases of the development process. At the same time,continuousmodelconsistencyhastobeassured.

RWF08 LightweightModelingApproach: In contrast to existing heavyweightmodeling approaches, themodels, notations and methodology forspecifyingworkflowbasedWebapplicationsshouldbestakeholderoriented,i.e.hidingtechnicalcomplexityandfocusingontheessentials,thusfosteringsimplicityandusability.

RWF09 Use of Standards: Existing standards in the fields ofmodelingnotations,process andworkflow languages, interchange formats aswell asexistingtoolsshouldbeincorporatedwherepossible.

2.3 WebbasedDialogsasPrimaryInteractionMediums

Complex dialogs with comprehensive underlying data models as well as a highintensity and complexity of user interaction aspects are gaining increasingimportanceintodaysWebapplications(O'Reilly2005;Phifer,Gootzit,Sholleretal.2007). Particularly in workflowbased Web applications, Webbased dialogsrepresenttheprimarymeansforwork.Forexample,inthepresentedbusinesstripprocess excerpt (cf. Figure 21), the greatmajority of tasks, e.g. Create ExpenseReport,correspondstodialogbaseduserinteractionwithinaworkflowbasedWebapplication.Consideringthesignificantcomplexityofmostofthesetasksaswellasthe comprehensive underlying data models, highly dynamic dialogs reducingcognitiveoverloadandofferingguidancetotheusersarerequired.

Inthe following,universallyvalidchallengesandrequirements fortheconstructionandevolutionofsuchadvancedWebbaseddialogswillbeelaboratedbasedontheTravelExpenseReportdialog, (e.g. (Karlsruhe InstituteofTechnology2009)).Thetravelexpensereport includespersonaldata,thedetailedtravel itineraryaswellasall incurredexpenses.Thus,theassociateddatamodel isquitecomprehensiveandincludes several contextdependent elements. For example, the requiredinformationdiffersdependingonthetraveldestination(national/international)andtheusedmeansoftransport(e.g.train,plane,car).

2.3WebbasedDialogsasPrimaryInteractionMediums 23

As theWebbaseddialogsusability is strongly interrelated to theusersefficiencyandeffectiveness incompletingthetask(Nielsen2005),the integrationofusabilityfactorsinadevelopmentmethodologybecomesasuccessfactor(Matera,RizzoandCarughi2006).Beyondthat,severalstudiesprovedthatthegeneralconsiderationofusabilityaspectsduringthedevelopmentprocesscanleadtosignificantcostsavingsby decreasing the amount of later changes (Nielsen and Landauer 1993;Madsen1999).ThemostwidelyadopteddefinitionofthetermUsabilitywasintroducedbyNielsen(Nielsen1993):

Definition 2.3 Usability:Usability is a quality attribute that assesseshoweasyuserinterfacesaretouse.[]Usabilityisdefinedbyfivequalitycomponents: Learnability, Efficiency, Memorability, Errors, andSatisfaction.

Inthiscontext,learnabilityreferstohoweasyitisforuserstoaccomplishbasictasksthefirsttimetheyencounterthedesign.Efficiencyaddresseshowquicklyuserscanperform tasksonce theyhave learned thedesign.Memorabilitymeanshoweasilyandquicklyoccasionaluserscanreestablishproficiencyafteraperiodofnotusingit.Errors concerns thenumber and severityof errorsmadebyusers aswell ashowgoodthesystemsupportsusersbothinpreventingandcorrectingthem.Satisfactioncovershowpleasantitisforuserstousethedesign.

Tothisend,guidelinesandbestpractices fortheusabilityorienteddesignofWebbaseddialogshavebeendeveloped (Nielsen2005;Preciado, Linaje,Sanchezetal.2005;Wroblewski2008):

Reducingcognitiveoverloadbysemanticpartitioning Selectiondependentinputs Incontexthelpandhints Immediatefeedbackandmeaningfulerrorindication Consistentformlayout Clearpathtocompletion Visualcontinuity

However, the implementationof suchusability features still remains complex anderrorprone. Above all, developers have actually to be aware of such usabilityprinciplesandbestpractices.Thefactthata largeamountofWebsitesstill ignoreswelldocumentedusabilityguidelinesandbestpractices(NielsenandLoranger2006)highlights thenecessityof integratingusabilityaspectsalready in thedialogdesignand development. ExistingWeb Engineeringmethodologies and commercial formdevelopment tools leave theenforcementofusability factors to theattentionandperceptionofdesignersanddevelopers.Evenworse,manyofthemimplicitlysuggesta rather static form design known from paperbased forms, thus neglecting thepotentialsandexpectationsforWebbaseddialogs.

A significant proportion of improvements could already be implemented atdevelopment time instead of being recognized in later usability tests. This oftenresultsdependingonthetimeof identification inadditionaldevelopmentcyclesoreven costly redesignprojects,e.g. (Herman2004).Consequently,models, toolsandmethodologiesshouldinherentlyaddressusabilityaspectsandprovideguidance

24 Chapter2ProblemScope

tothedeveloper.Inthisregard,userinteractionpatternscanbehelpful(WelieandTrtteberg2000).

Beyond theseusabilityaspects,Webbaseddialogsshouldbeusableplatformanddeviceindependently,wherebyeachdevicecanpossessdifferentcharacteristicssuchasscreenresolution.Withrespecttothetravelexpensereport,travelersmightwanttofilloutpartsoftheexpensereportduringtheirjourneyusingamobiledevice(e.g.a PDA).An adequate engineeringmethodology aswell as an associated technicalframework should be capable of adapting a dialog to the characteristics ofrequestingclientdevicesatruntime.Inthiscontext,designmodelsshouldallowforspecifying rulebased guidelines on how a dialog may be adapted in order topreserveitsusability,e.g.regardinglogicalpartitioning.

Besides these dialogspecific requirements, further challenges arising from adevelopment and project management perspective exist (Freudenstein andNussbaumer 2008b). As already mentioned in Section 2.2, Web applications ingeneral andworkflowbasedWeb applications in particular underlie a continuousevolutiondue to frequentchanges.Thisholds trueespecially for theirdialogs,e.g.duetoadaptations inthedatamodel,designor layoutchanges,orcompletelynewrequirements(Pressman2005b).Thus,asuitabledialogengineeringapproachshouldbeagile in termsof supporting short revision cycles and theefficient adoptionofchanges.

Fromthetechnicalpointofview,the integrationofWebservicecommunicationforretrievingupdatesofthedialogsdatamodelorforsubmittingthefinaluserinputisa common requirement found in serviceoriented and workflowbased Webapplications. Regarding the travel expense report example, Web servicecommunicationcouldberequiredtosubmittheexpensereporttoalegacybackendsystemortoprovideautocompletionfeaturesusingexternalWebservices.Hence,datamodelsinformofXMLSchemaspecifications(Thompson,Beech,Maloneyetal.2004)or integrated inWebServiceDescription Languagedocuments (Christensen,Curbera,Meredithetal.2001)usually forma startingpoint for thedialogdesign.With respect to requirements related to development efficiency and rapidprototyping, the automated generation of running, Web serviceenabled dialogsbasedonsuchdatamodelsisdesirable.

An additional requirement arising from a technical perspective concerns theresulting dialogs implementation language. As powerful standardized markuplanguages for the technical implementation of Webbased dialogs have beenintroduced inthe last fewyears,e.g.XFormsbytheW3C (Boyer,Dubinko,LeighL.Klotzetal.2007)orXAMLbyMicrosoft(MacVittie2006),theirpotentialsshouldbeleveragedinanengineeringapproachforadvancedWebbaseddialogs.Thereby,onthe one hand, the extensibility and reusability of the resulting dialogs can beimproved.Ontheotherhand,theengineeringapproachsapplicabilityandutilitycanbe increasedaswellas thedisseminationof thesenewmarkup languages canbesupported.

Throughout thedevelopmentprocessesof thevariousWebbaseddialogswithinaworkflowbased Web application, a multitude of stakeholders from differentorganizationalunitswithdiverseprofessionalbackgroundsandskill levelshastobe

2.3WebbasedDialogsasPrimaryInteractionMediums 25

involved. Inorder to improve theefficiencyandeffectivenessof thecollaboration,theemployedmodelingnotationshavetobeassimpleandintuitiveaspossibleandshould focusonrelevantdialogspecificaspectswhilehidingunwantedcomplexity.Furthermore, an associated, easytouse editor for creating and adapting dialogmodels is desirable. Such an editor would ideally be Webbased, thus easinglocation and platformindependent development. Assuming the existence ofeffective approval processes, stakeholders could thereby autonomously performmodificationsandextensionstoexistingdialogmodelsorevendesignnewones.

Evolutionary prototypes or the completely automated transformation of dialogmodels into running dialogs respectively, can help to achieve a commonunderstanding and to identify discrepancies between requirements and theirrealization (Wiegers2003).Designalternatives,e.g. targetingusabilityaspects,canbe explored andmisunderstandings canbe resolved at an early, yet costefficientpointoftime.

Considering the immense number of Webbased dialogs being developed at auniversityovertime,thestrongintegrationofreuseinallphasesofthedevelopmentprocess is desirable. The systematic reuse of various artifacts, e.g. data models,dialog models (in part or whole), as well as software components contributesparticularlytodevelopmentefficiencyandsoftwarequality(cf.Section2.4).

2.3.1 RequirementsCatalogfortheDimensionDialog

The following catalog briefly summarizes the identified requirements for theproblemdimensionDialog:

RD01 Usability: An adequate engineering methodology should treatusabilityaspectsasvitalfeaturesofadvanceddialogs.Thus,itshouldprovideguidanceandstrongsupportfortheefficientimplementationofhighlyusableWebbaseddialogs.

RD02 Device Independence: The resulting dialogs should be accessibleand usable deviceindependently. Therefore, they should be reasonablyadaptedtoclientcharacteristicsatruntime.

RD03WebServiceSupport:Webserviceendpointsshouldbeconsideredas an important submission channel for completed dialogs. Thus, theautomatedgenerationof runningWebserviceenableddialogsaccording toWSDLbasedorXMLSchemabaseddatamodelsshouldbesupported.

RD04 Agility and Evolution: A dedicated dialog engineering approachshouldbeagileandevolutionoriented intermsofsupportingshortrevisionlifecyclesandtheefficientadoptionofchanges.Therefore,itshouldallowforefficientlyconstructingandevolvingadvancedWebbaseddialogsonapuremodelbasis.

26 Chapter2ProblemScope

RD05 Stakeholder Involve