Min erfaring er at mange interaksjonsdesignere synes det er vanskelig å finne sin plass i en smidig hverdag, hvor krav og retning kan endre seg raskt. Der metodikken tidligere har vært å designe en helhetlig brukeropplevelse før utviklingen begynner, må interaksjonsdesignere nå ha flere fokus samtidig. I et landskap som oppfordrer til endring og avvik fra plan, må man forsøke å ligge et hestehode foran utviklerne til enhver tid – samtidig som det er forventet at man greier å løfte blikket og lage en langsiktig plan for applikasjonen.

En interaksjonsdesigners oppgaver

Under følger en beskrivelse av de forskjellige oppgavene til en interaksjonsdesigner. Jeg har forsøkt å prioritere oppgavene med de viktigste først. Merk at jeg har valgt å fokusere på noen få oppgaver; de mest sentrale sett fra mitt daglige virke som utvikler. I realiteten gjør interaksjonsdesignere uendelig mye mer, og har en enorm verktøykasse.

Daglig oppfølging

Den viktigste jobben en interaksjonsdesigner gjør er å følge opp utviklingen fra dag til dag. Det vil si å «henge over» utviklerne og passe på at all funksjonalitet som lages er god nok. Helst bør dette gjøres som en fast del av utviklingsprosessen – gjerne som et akseptansekriterium innenfor hver iterasjon. Ethvert krav som toucher frontend bør først diskuteres med en interaksjonsdesigner – gjerne resulterende i omtrentlige papirskisser for løsningen. Deretter skal den ferdige implementasjonen finpusses og godkjennes før kravet kan sies å være ferdig. Skal dette fungere er det viktig at utviklerne også fokuserer på å involvere og imøtekomme interaksjonsdesigneren, slik at det ikke blir en «vi mot dem»-holdning.

Dersom man ikke har nok ressurser til å ligge i forkant innenfor hver enkelt iterasjon, kan man legge inn i prosessen at ingen krav er klare til utvikling før interaksjonsdesignet er ferdig. Dette vil redusere behovet for daglig oppfølging og gjøre det lettere å prioritere i hvor stor grad hvert enkelt krav skal detaljeres.

Skissere målbilde for applikasjonen

Den neste viktige jobben er å skissere et målbilde for hele applikasjonen. Målbildet er et ideal for hvordan applikasjonen kan bli seende ut når den er ferdig, og bør brukes til å bygge og prioritere backlog. Det er viktig å styre forventningene, slik at man ikke kommer i en posisjon der man ikke får satt noe i produksjon før målbildet er nådd og alt er implementert. Å balansere mellom målbilde og daglig oppfølging kan være vanskelig; man bør være i stand til å produksjonssette deler av løsningen ofte, mens man fortsatt sikter mot idealbildet for hele applikasjonen.

Skissering av målbilde bør også inneholde utprøving av enkeltkomponenter, for eksempel ved hjelp av papirskisser eller prototyper, slik at man unngår ubehagelige overraskelser sent i utviklingen.

Brukertester

For å sikre at man er på rett spor kan det være nyttig å hente inn feedback ved å gjennomføre brukertester av løsningen. Dette bør ikke utsettes til man anser hele applikasjonen som ferdig, men heller gjentas flere ganger under utviklingen dersom ressursene tillater det. Hvis man får produksjonssatt løsningen tidlig, bør man selvsagt også følge opp de tidlige brukerne.

Avslutning

Denne introduksjonen til hvordan interaksjonsdesign kan passe inn i smidig utvikling kan kanskje best avsluttes med et fritt gjengitt sitat av Mary Poppendieck: «Maybe we shouldn’t be thinking about how we fit usability into agile, but how we can fit agile into usability». Å skape verdi handler ikke om domenemodeller, rammeverk eller programmeringsspråk. Verdi dreier seg om å tilfredsstille og begeistre kundene dine! Dette må vi som programmere innse at det er andre som kan bedre enn oss.

Validering av input er ikke løsningen
Tidligere snakket man ofte om at manglende validering av input var årsaken til disse feilene. Dette er dessverre ikke riktig. Validering av input handler om å sjekke at input er riktig i forhold til domenet. Dette vil riktignok stoppe mange angrep, men på langt nær alle. Et godt eksempel er navnet “Ken-Martin O’Conner”. Dette etternavnet inneholder flere tegn som også er kontrolltegn i SQL. For å kunne godta dette navnet må man ved validering av input godta bånde bindestrek og fnutter. Dermed vil man også tillate et angrep som ' OR '' LIKE '' --. Man kan selvsagt forsøke å gjøre valideringen enda strenger, men man risikerer kjapt å avvise gyldig input.

Jeg sier ikke at validering av input er unødvendig – det er bare ikke løsningen på dette problemet.

Kontekst og escaping
Problemet ved både XSS- og SQL-injection-feil er at data flyter fra en kontekst og over i en annen. Ved overgang fra f.eks. javakode til SQL, må vi sørge for at vi beholder semantikken. Skal vi sette inn en datastreng i en SQL-spørring, må vi sørge for at det forblir en streng. Dette gjør vi ved å foreta output escaping. For SQL er løsningen enkelt og greit å ta i bruk parameteriserte spørringer (prepared statements). Bruker vi prepared statements og gir inn parametrene i etterkant, vil rammeverket håndtere escaping av kontrolltegn for oss.

For XSS er det desverre noe vanskeligere. Når data forlater vår applikasjon og går over til noe browseren skal tolke, er det nemlig flere mulige kontekster. Vi kan skrive ut innhold i javascript, javascript i HTML, mellom HTML-tagger, i HTML-attributter osv. Og flere av disse kontekstene må behandles forskjellig. Vi kan begynne med input som skrives ut mellom HTML-tagger. Dette er den enkleste konteksten. Vi kan bruke dette eksempelet:

<div>Du søkte på "her kommer inputten"</div>

For å hindre kjøring av script her, må vi sørge for at input ikke kan åpne nye tagger, f.eks. en <script>-tag. Dette gjør vi selvsagt da ved å erstatte > med > og < med <.

I HTML-attributter, må vi også passe oss for enkle eller doble fnutter alt etter hva som er brukt. Et eksempel på denne konteksten kan være:

<input type="text" value="her kommer inputten"  name="searchValue" />

Et typisk angrep ville i dette tilfellet ha brutt ut av value-attributtet og åpnet en javascript-event (f.eks. onclick eller onmouseover). Her må vi altså " med &quote; og ' med ' eller '. Men i noen tilfeller glemmer utviklere å bruke fnutter til å avgrense attributtverdier, så til og med et mellomrom kan lede til problemer.

Ser vi på javascript i HTML, kan det se slik ut:

...
<body>
<script>
var searchTerms = 'her kommer inputten';
</script><code>
...
</body>
...

Her er det kanskje lett å tenke at det holder å legge til en backslash forann eventuelle enkle fnutter (' blir til \'), men vi må huske at vi er i en såkalt dobbel-kontekst: Javascript-kontekst inni en HTML-kontekst. Vi må derfor også passe oss for HTML-tegn. Her er et eksempel på hvorfor man må escape for begge kontekster.

For mer informasjon om de forskjellige XSS-kontekstene, se OWASP XSS Prevention Cheat Sheet.

For .NET finnes det et bibliotek kalt Web Protection Library. Dette biblioteket har en komponent som heter AntiXSS, som kan escape for forskjellige kontekster. For Java kan man f.eks. benytte encoderen i ESAPI.

Oppsummert
Beskyttelese mot disse angrepene må gjøres med kontekstbasert escaping idet vi bytter fra en kontekst til en annen.

I en nylig publisert undersøkelse fra Dataforeningen konkluderes det med at 8 av 10 norske bedrifter har bestemt seg for å bruke sosiale medier – dette er 25 % mer enn for et halvt år siden. Undersøkelsen sier videre at 74% prosent av norske virksomheter har hatt sosiale medier som tema for diskusjon i ledergruppen. 67% av respondentene i undersøkelsen mener at virksomheter som ikke har en strategi for sosiale medier vil møte problemer. Det er altså ingen tvil om at holdningene til sosiale medier er i kraftig endring i norske bedrifter!

Skeptisk?

Motargumentene mot store norske virksomheters tilstedeværelse i sosiale medier vil alltid være tilstede. Frykt for at brukerne på sosiale medier er negative, angst for delekultur og åpenhet og spørsmål rundt personvern og IT-sikkerhet er vanlige motargumenter mot å ta skrittet ut i de sosiale medienes verden. Men veier fordelene opp for ulempene?

Sosiale medier har sine fordeler!

En bevisst tilstedeværelse i sosiale medier gir mulighet til å utnytte markedets engasjement for selskapets merkevare(r) til selskapets fordel. Dialog i sosiale medier fostrer innovasjon – ideer  til forbedring oppstår lettest gjennom dialog og samspill. Sosiale medier er som skapt for dette. Bedrifter som lytter til varepraten i sosiale medier, og bruker dette aktivt i sin forretningsutvikling, utvikler produkter som kundene vil betale for!

Sosiale medier byr på en unik mulighet til å synliggjøre bedriftens handlekraft og smidighet. Hvilke andre muligheter har en bedrift til å fortelle markedet daglig om hva man gjør for å utvikle bedre produkter og tjenester og hvordan man jobber for sine kunder? Benytter man seg av mulighetene de sosiale mediene gir bygger man etter min mening omdømme med en effektivitet som tidligere var umulig.

Trenger man en strategi for sosiale medier da?

Varepraten og dialogen om virksomheter går i de sosiale mediene uansett, man må forholde seg til disse mediene enten man vil eller ikke. Edgar Valdmanis i Dataforeningen oppsummerer dette på en glimrende måte: ”Dine ansatte er der, dine kunder er der, dine leverandører er der. Hvis du neglisjerer dette, er det på egen risiko!”

Store norske virksomheter bør derfor investere tid og ressurser i å utarbeide en strategi for sin tilstedeværelse i sosiale medier. Strategien bør gjøres lett tilgjengelig for alle ansatte – enkelhet og evnen til å fatte seg i korthet er suksessfaktorer i så måte. Som et minimum bør en strategi for tilstedeværelse i sosiale medier klart definere hva man ønsker å oppnå (mål), hva man skal gjøre (satsingsområder) og hvor man skal gjøre det (Twitter? Facebook? Egen blogg? Eget nettsamfunn?).

Investering i strategi vil tilbakebetales!

Investeringen i en strategi for tilstedeværelse i sosiale medier vil tilbakebetales gjennom økt effekt av ressursbruk på sosiale medier og økt seriøsitet i sosiale medier.

Økt effekt av ressursbruken på sosiale medier oppnår man gjennom at strategien gir en klar retning og et fokus til satsingen i sosiale medier. Dette forenkler prioritering av ressursbruken på sosiale medier og man unngår bruk av ressurser på områder der forventet effekt er lav.

Bedrifter som har en strategi for tilstedeværelse i sosiale medier opplever økt grad av seriøsitet i sosiale medier blant de ansatte. Ansatte som er trygge på at ledelsen har en plan for bedriftens tilstedeværelse i sosiale medier unngår å ”ta ansvar” for å svare på bedriftens vegne når de finner det for godt. Wimpgate og Warnerfail er eksempler de fleste bedrifter forsøker å unngå.

For å etablere en profesjonell tilstedeværelse i sosiale medier trenger man altså en strategi som definerer fokus for tilstedeværelsen. Det å definere fokus handler mer om å velge bort enn å velge. Hva vil vi oppnå med vår tilstedeværelse i sosiale medier? Hva skal vi gjøre i sosiale medier? Hvordan skal vi fremstå? Hvilke kanaler skal vi bruke? Hvilke avdelinger eller forretningsområder skal være ansvarlige?

Dette er sentrale spørsmål som må besvares i en strategi for tilstedeværelse i sosiale medier. Og ja, jeg mener at DIN bedrift trenger en strategi for tilstedeværelse i sosiale medier!

Når man planlegger et utviklingsprosjekt for web vil dette som oftest innebære et valg av webrammeverk. Det er etterhvert blitt svært mange å velge blant, og det kan være en utfordring å få oversikt over hva som skiller de ulike rammeverkene. Tradisjonelle action-baserte webrammeverk som Struts2 og Spring MVC har modne og velprøvde API, og blir ofte valgt fordi man her har erfaring fra før og fordi rammeverkene støttes av en stor community. Men blant alternativene som bør vurderes finnes en rekke komponent-baserte rammeverk med en mer høynivå tilnærming. Disse rammeverkene lover rask og effektiv utvikling med et minimum av konfigurasjon, og konfigurerbare, kraftige komponenter som holder på sin egen tilstand og gir rik funksjonalitet rett ut av boksen. Rammeverkene er ment å være utviklervennlige, med utstrakt implementasjon av best pactices.

Tapestry er et open source komponent-basert webrammeverk som har vært under utvikling siden starten av 2000-tallet. Med versjon 5 har rammeverket fått mye oppmerksomhet og positiv omtale. I likhet med Wicket er det nå tatt inn som et Apache-prosjekt, noe som betyr at kildekoden er tilgjengelig med Apache Software Licence 2.0.

Hvorfor skal så du vurdere dette rammeverket kontra tradisjonelle action-baserte webrammeverk?

Utviklerne bak Tapestry har definert fire egenskaper som de anser som de viktigste for et rammeverk:

• Enkelhet – å utvikle webapplikasjoner skal ikke trenge å være så komplisert. Mye kompleksitet blir håndtert av rammeverket, som utvikler skal du få fokusere på forretningslogikk.

• Konsistens – Rammeverket skal ha en konsistent oppførsel, med komponenter som er “self contained”, altså holder på sin egen tilstand. Webapplikasjoner lagd med Tapestry skal ha en uniform struktur og utviklere skal kunne bygge på best practices.

• Effektivitet – Applikasjoner basert på Tapestry skal ha god ytelse og skalerbarhet. Utviklingsprosessen skal også være så effektiv som mulig.

• Tilbakemelding – Rammeverket skal gi god og relevant informasjon til utvikler hvis feilsituasjoner oppstår.

Hvordan er så dette implementert i Tapestry 5?

Enkelhet

En webapp lagd i Tapestry består av et sett med sider som håndteres av rammeverket. En side består av en template (med en eller flere gjenbrukbare komponenter) og en tilhørende javaklasse med samme navn. Javaklassen er en POJO uten avhengigheter til andre deler av rammeverket; ingen superklasse som må extendes, ingen interface må implementeres.

Denne understøttende javaklassen tilsvarer en Controller i et action-basert rammeverk, og håndterer events som kommer fra viewet. Dette ligner mye på måten tradisjonelle desktop-applikasjoner fungerer, og innebærer et høyere nivå av abstraksjon fra request/response-modellen som f.eks Struts2 og Spring MVC bruker. Urler og request-parametere er erstattet av metoder og egenskaper ved side-objekter. Komponenter er også bygget opp på samme måte; en template og en javaklasse med samme navn, uten avhengigheter. Bruken av POJOs gjør det lett å lage egne testbare komponenter, samt å utvide eksisterende komponenter.

Så hvordan kan Tapestry sette sammen templates og tilhørende javaklasser når disse ikke arver fra en rammeverkspesifikk superklasse eller implementerer bestemte interfaces? Tapestry bruker bytecode weaving til å legge til tapestryspesifikk kode ved runtime. Dette skjer ved at sider og komponenter bruker annotations for å beskrive hvordan rammeverket skal håndtere koden. En kan også bruke navnekonvensjon på metoder som lytter på events, og dermed redusere bruken av annotations. Den utstrakte bruken av annotations og navnekonvensjoner øker lesbarheten og reduserer mengden boilerplate kode.

En siste viktig detalj mht enkelhet er at konfigurasjon gjøres programatisk i en egen javaklasse. Dette gir svært lite deklarasjon i XML å forholde seg til, kun web.xml. Tapestry kommer med en defaultkonfigurasjon som man kan utvide og endre ved behov.

Konsistens

Et viktig designprinsipp for Tapestry er “convention over configuration”. Sider, komponenter, templates, services etc må ligge i bestemte kataloger, og følge bestemte navnekonvensjoner. Det man tjener på dette er redusert behov for konfigurasjon, samt en konsistent struktur på webapplikasjonen.

Alle komponenter er self-contained og kan plasseres på hvilken som helst side. De holder sin egen state uten behov for parametere.

Effektivitet

I likhet med andre komponentbaserte webrammeverk er Tapestry svært velegnet til prototyping og rask utvikling av webapplikasjoner.

Kraftige, gjenbrukbare komponenter gir mye funksjonalitet ut av boksen, og disse er enkle å modifisere og utvide. Det er også enkelt å utvikle egne komponenter. Rammeverket kommer med bl.a URL-håndtering, mulighet for tilstandshåndtering på klient eller server, inputvalidering, internationalization, AJAX-støtte og feilrapportering innebygget, og integrasjon mot en rekke kjente rammeverk som Spring og Hibernate er inkludert.

Som utvikler ønsker man å produsere mest mulig funksjonalitet raskest mulig, med færrest mulig feil. Code-test-deploy roundtrip bør derfor være så kort som mulig, og rammeverket må understøtte testdrevet utvikling. Nettopp effektivitet og testbarhet er blant Tapestrys sterkeste kort.

Med live class reloading av alle komponent-klasser trenger man ikke redeploye aplikasjonen for å se resultatet av en endring i koden. Tapestry har en egen classloader som ser etter endringer i koden, og dette muliggjør høy produktivitet. Ettersom komponentene i Tapestry håndterer sin egen tilstand og eventhandling abstraherer bort mye kompleksitet kan utviklere heller konsentrere seg om forretningslogikk. Tapestry er også velegnet for TDD, med sider og komponenter som er POJOs uten avhengigheter til rammeverket.

Et annet viktig prinsipp for Tapestry er “static structure, dynamic behavior”.
Med dette menes at strukturen til en gitt side er statisk mens logikken i komponentene gjør at sidene likevel er dynamiske. Med en statisk instans av strukturen for en side kan denne pooles av rammeverket. Dette gjør at en side som aksesseres flere ganger vil gjenbrukes, noe som er gunstig både for ytelse og skalering. Tapestry lagrer mindre data i HttpSession enn andre komponentbaserte rammeverk som JSF og Wicket, fordi bare data fra en side lagres, ikke hele side-instansen.

Tilbakemelding

Når en feilsituasjon oppstår vil Tapestry gi utvikler en detaljert og informativ feilmelding. Feilmeldingen vil referere til riktig kodelinje i den originale kildekoden, med et utsnitt av den aktuelle kodebiten og en mulig feilårsak og løsning.

Så er alt bare gull og Tapestry 5 et soleklart valg i ditt neste prosjekt?

Det er endel aspekter man bør være klar over når man vurderer Tapestry.

Rammeverket har fått endel pepper for manglende bakoverkompatibilitet ved major releases. Versjon 5 er en omfattende omskrivning ift v4, og en migrering av et eldre prosjekt vil være tidkrevende. Nå loves det fra utviklerne at man f.o.m v5 ikke skal få dette problemet så lenge selve grunnkonseptene ikke endres.

Komponenter som håndterer sin egen tilstand gjør at man kan få mye data i session scope og dermed stort minneforbruk; dette er en generell problemstilling for komponentbaserte webrammeverk. Tapestry håndterer dette vha førnevnte side-pooling og lagring kun av data for en side i session. Man kan også optimalisere applikasjonen ved å sette en grense for antall sider i session.

Bruken av en pool med side-instanser begrenser også den potensielt uheldige effekten for ytelse som runtime bytecode weaving kan ha. Sider vil ta kun ta lenger tid å laste ved førstegangs aksess, så dette er ikke et større problem i Tapestry enn f.eks i JSP.

Feilsøking i generert tapestrykode kan være frustrerende. Koden du har skrevet blir vevd sammen med tapestrykode runtime, og en bug kan ligge i koden fra rammeverket. Du har da muligheten til å sette loglevel til DEBUG, og få ut logg for den endelige, genererte koden.

Lærekurven kan være bratt hvis man tidligere kun har skrevet webapplikasjoner i action-baserte rammeverk. Erfaring fra utvikling av desktop-applikasjoner vil være relevant for det programmeringsparadigmet man bruker i Tapestry. Dokumentasjonen er blitt mye bedre med versjon 5, og veien til den første Hello World-applikasjonen er ikke lang.

Tapestry har færre brukere og aktive commiters enn f.eks Struts2, Spring MVC og JSF, men community er i vekst nå som Tapestry er blitt et Apacheprosjekt.

Konklusjon

Hvis du skal vurdere webrammeverk til en applikasjon med et rikt GUI og ønsker å utvikle dette uten bruk av plugins må komponentbaserte webrammeverk vurderes. Med Apache i ryggen og en økende brukermasse er Tapestry 5 et webrammeverk i positiv utvikling.

Tapestry gir deg et bibliotek med kraftige, utvidbare og godt dokumenterte komponenter, og sikrer en rask utviklingssyklus med live class reloading. Rammeverket forenkler utvikling av rike GUI for web og er godt egnet for testdrevet utvikling. For å oppnå enkelhet ved utvikling må man ofre noe fleksibilitet. Ved å akseptere de valg som er gjort i rammeverket får man konsistens, på bekostning av ubegrenset mulighet til å implementere egne patterns.

Tapestry 5 bør være på lista når webrammeverk skal velges i ditt neste prosjekt.

UK-based super hacker and long time Cucumber contributor Rob Holland announced iCuke yesterday. iCuke is a Cucumber extension that lets you write automated functional tests for iPhone apps. Here is a little teaser…

iCuke from Aslak Hellesøy on Vimeo.

For questions about iCuke, please use the iCuke mailing list.

Blant konferanseforedragene var Avinors erfaringer med offentliggjøring av data (som du også kan lese mer om her), Norwegians sofistikerte og sammensatte arkitektur for flyreservasjon, samt NAVs nye stillingssøk basert på søkemotoren Solr. Sistnevnte ble filmet, se foredraget til NAVs portalansvarlig Magnus Børnes Hellevik sammen med Carl Christensen lenger ned.

“Jeg har sett mange gode arkitekturer som aldri ble noe av”

Dette sitatet (fritt etter hukommelsen) hørte jeg fra en foreleser på en konferanse for en tid tilbake. Min første tanke var: “var arkitekturen god hvis den ikke ble noe av”? Hvis vi igjen skal se på gode, gamle Vitruvius som jeg nevnte i mitt forrige innlegg; oppfyller arkitekturen som ikke ble noe av ikke prinsippene firmitatis utilitatis venustatis? Ikke var den robust, ikke var den nyttig for brukerne og den fikk aldri sjansen til å vise sin skjønnhet. Vel. Mer fruktbart er det kanskje å spørre seg hvorfor en arkitekturplan aldri ble noe av. Det kunne være at den ble for dyr, det kunne være at den ikke løste utfordringene den skulle eller det kunne være at den ikke hadde tilstrekkelig forankring i organisasjonen. Like viktig som hva en arkitektur består av, er hvordan den ble til.

Arkitektur ikke bare en arkitekts anliggende

Arkitektur er et tverrfaglig område. Det omhandler forretningen (hvilken funksjonalitet er ønsket, og hvilken verdi gir den?), økonomi/finans (hva er kostnadene? Oppstartskostnader vs. operasjonelle kostnader, osv.) og ikke minst teknologi (modenhet, tilgjengelighet, osv.). En god arkitekturprosess krever forankring og involvering fra ulike deler av organisasjonen og jo mer eierskap de involverte føler, jo større er sjansen for å lykkes. Et eksempel på dette er smidige utviklingsprosjekter, der arkitekturspørsmål bør kunne diskuteres og løses i utviklingsteamet. I den grad man har arkitekturprinsipper som går på tvers av prosjekter, bør man sikre tilstrekkelig involvering på tvers av prosjekter, f.eks. gjennom at arkitekter dedikeres til prosjektene og kan jobbe tett med utviklingsteamene.

Arkitektur og “Big Design Up Front”  – BDUF

I mitt tidligere innlegg pekte jeg på at arkitektur er en delmengde av design i den forstand at design kan skje på alle granularitetsnivåer og kan gjerne omhandle en moduls eller applikasjons interne organisering, mens arkitektur fokuserer på helheten og eksterne kvaliteter. I smidige prosjekter ønsker man å unngå det man kaller “big design up front“, altså at design skjer før utviklingen eller implementasjonen starter. Dette er et prinsipp som brukes uavhengig av hvilke smidige metoder som benyttes, men jeg syns Lean Software Development er nærmest å forankre prinsippet teoretisk. I mine øyne er fravær av BDUF en følge av tre Lean-prinsipper: 1) vektlegge læring, 2) ta avgjørelser så sent som mulig og 3) mindre avfall, “eliminate waste”. Ved å kjøre designprosessen som en del av utviklingsprosessen kan man ta med seg læring inn i designprosessen. Videre kan man utsette designavgjørelser lengre slik at man har mer informasjon og kunnskap tilgjengelig som beslutningsgrunnlag og dermed forhåpentligvis ta en bedre avgjørelse enn man kunne gjort tidligere. Til sist, hvis design gjøres samtidig som implementasjonen, sparer man unødig ressursbruk til dokumentasjon i og med at de involverte har informasjonen i mente allerede. Mer om dokumentasjon senere…

Spørsmålet er om regelen om å unngå “big design up front” også gjelder for arkitektur? Ja og nei. Noen arkitekturavgjørelser må ofte tas før man starter implementasjon. Dette kan for eksempel være hvilken implementasjonsplattform man ønsker å bruke (Java EE eller .NET, for eksempel). Det som er viktig i slike sammenhenger, er som jeg nevnte i forrige avsnitt at man utsetter avgjørelser som er vanskelig å omgjøre så lenge som mulig. Spesielt viktig er det også å utsette avgjørelser som introduserer mye kompleksitet så lenge som mulig fordi kompleksitet ofte introduserer avhengigheter. Disse bidrar så til å krympe mulighetsrommet for arkitekturen. Med andre ord får man mindre frihetsgrader. I den grad man kan gjøre det, bør man fatte avgjørelser som kan omgjøres for å unngå å male seg inn i et hjørne. Et godt innlegg om det å utsette avgjørelser finner du her.

Et dokument er ikke arkitektur

“Leveransen fra arkitekturprosessen er et arkitekturdokument”. “I følge rammeverk X skal leveransen fra arkitekturprosessen være et Y-diagram, en Z-modell, … , samt en forretningmodell”.  Lyder kjent? Å ha noe håndfast (i den grad man kan omtale et elektronisk dokument som håndfast, man kan i det minste skrive det ut for å få noe håndfast) å vise til som resultat av en investering gir en god og varm følelse. I klassisk transaksjonstankegang er dette viktig fordi det er et synlig bevis for hva man har fått igjen, og et sett arkitekturprinsipper som eksisterer inni hodene på folk ikke gir den samme følelsen av å ha fått noe tilbake.

Å benytte et rammeverk for arkitektur som definerer et sett av dokumenter som skal produseres gir også troverdighet som det er behagelig å lene seg på. Dette er selvfølgelig vissvass. Et arkitekturrammeverk er et tomt skall uten innhold, og det er innholdet som er viktig.

Arkitektur består av en del fokusområder / kvaliteter (eksempelvis firmitatis utilitatis venustatis). Disse er i stor grad ideer eller prinsipper, og det er veldig vanskelig å formidle ideer og prinsipper i dokumenter. Enklere er det derimot å overføre ideer muntlig, og enda bedre; hvis man selv har vært med på å komme frem til disse har man en enda bedre forståelse (og ikke minst et større eierskap). Dokumenter er den dårligste kommunikasjonsformen, og burde brukes når andre former ikke er tilgjengelige. Dette kan være tilfelle på grunn av avstand til brukere; både organisatorisk, geografisk og i tid. Som jeg nevnte i forrige avsnitt; den organisatoriske avstanden bør minimeres gjennom involvering, og som jeg nevnte i avsnittet om BDUF, avstanden i tid bør minimeres ved å utsette arkitekturavgjørelsene så lenge som mulig.

Oppsummering

Gjennom disse to innleggene om arkitektur har jeg vært innom flere aspekter som kan oppsummeres som følger:

1. Arkitektur fokuserer på helheten og på eksterne kvaliteter (hva som er eksternt varierer dog avhengig av perspektivet)
2. Arkitektur består av en del kvalitetsområder eller prinsipper, eksempelvis firmitatis utilitatis venustatis
3. Arkitekturarbeid er en tverrfaglig prosess der involvering fra ulike deler av organisasjonen er viktig
4. Arkitektur bør utvikles gradvis, parallelt med implementasjon der man underveis nyttiggjør seg lærdom man opparbeider seg
5. Leveransen fra arkitekturarbeid bør ikke defineres i form av dokumenter. Kommunikasjonsformen bør tilpasses situasjonen.

Har du rusk i rørene? Selvfølgelig er jo Plumbo effektivt der og da – hell litt i røret, vent, skyll med masse varmt vann og rørene er så gode som nye! Eller? Nei… Det er en grunn til at det står på Plumbo-flasken at den ikke må brukes på ditt og datt rør. (Ettersom jeg ikke eier Plumbo klarer jeg ikke å sitere flasken heelt riktig). Men, jeg vet at Plumbo er skadelig for rørene dine, særlig når man har en leilighet fra 1936. I tillegg fungerer det jo bare en liten stund. Hvorfor? Fordi du ikke har fikset roten til problemet.

Plumbo gir ingen tilfredsstillende følelse av å ha fikset problemet.  Det er som et lite hack – du vet at det virker, enn så lenge.

Med mindre du ikke vet bedre da. Men, den dagen du finner ut at Plumbo ikke er verdens smarteste ting å bruke i lengden – forhåpentligvis før rørene dine må skiftes – er det på tide å tenke litt lenger. Kanskje du faktisk må løfte på den risten, stikke hånden ned i røret og finne ut hvorfor vannet ikke renner ut som det skal. Det er ikke bare moro å tømme et rør for rusk, men følelsen i etterkant er myyye bedre. Ekstra smart føler du deg den dagen du finner ut at grunnen til at rusket havner i røret og tetter det er fordi risten som ligger over ikke er tett nok.

Brett opp armene og tør å bli skitten!

Og ja, jeg kom til å tenke på dette da jeg plutselig hadde skrudd fra hverandre hele toalettet mitt, fordi det laget lyder. Jammen meg fant jeg ut hvordan mekanismen for å få vann både inn og ut fungerte; hvordan toalettet har en enkel detektor flytende i vannet for å vite når det skal fylles igjen, hva som gjorde at det lakk og dermed laget lyder når det hele tiden måtte fylles igjen. Jeg kunne jo kalt inn en ekspert, men hvorfor det når man ved å plukke ting varsomt fra hverandre finner helt fint ut hvordan patenten fungerer og hvordan det skal settes sammen igjen.

Jeg hører fremdeles min fars stemme i hodet: “Ikke bruk makt” – hver gang jeg ikke helt forstår hvordan noe fungerer og har lyst å rive det fra hverandre. Dette minner meg om at med litt tålmodighet finner jeg alltid ut hvordan ting henger sammen. Hans moral var alltid at det finnes en patent. Finner man og forstår denne er det sjelden bruk for makt. I tillegg slipper man selvfølgelig å ødelegge ting, noe som er fornuftig når man har en innebygget nysgjerrighet som gjør at man bare _må_ sjekke inni alt som er av fjernkontroller og duppeditter for å se hvordan det fungerer. Det kan nå kanskje også nevnes at jeg ikke noengang, så godt jeg kan huske, har skrudd fra hverandre noe som jeg ikke har klart å sette sammen igjen.

Tar du deg tid til å finne patenten? Tør du å bli skitten til albuene? Kjøper du Plumbo eller ny rist til dusjen?

Arkitektur fokuserer på helheten

Selv om man skal være forsiktig med å trekke paralleller mellom arkitektur i IT-verdenen og den klassiske betydningen av arkitektur, er det interessant å studere etymologien for å få en forståelse av hva ordet har blitt brukt til og hva det har representert tidligere. Ordet arkitektur stammer fra gresk “arkitekton” (via latin “architechtura”) og er sammensatt av de to ordene “ὰρχι” (hoved- eller sjef-) og “Τεκτονική” (håndtverker, bygger). En arkitekt er altså en “sjefsbygger”.

Om arkitektur står det også å lese at den ble ofte kalt moderkunsten fordi den fokuserte på helheten (kilde: kunsthistorie.com). Dette er noe vi kan kjenne igjen daglig bruk av arkitektur i vår bransje. Arkitektur handler om helheten, de store linjene. Man kan snakke om “overliggende arkitektur”, selv om det muligens er smør på flesk, men det gir ikke noen mening å snakke om “detaljert arkitektur”. Man kan derimot snakke om “detaljert design”; til forskjell fra arkitektur er design noe som kan gjelde ulike granularitetsnivåer. Forskjellen mellom arkitektur og design er at arkitektur fokuserer på helheten og et systems eksternt synlige, ikke-funksjonelle kvaliteter, mens design gjerne kan omhandle interne kvaliteter. Eksempelvis er intern kodeorganisering som noe som omhandler design, men ikke arkitektur. Derimot er valg av plattform, f.eks. J2EE eller .NET, noe som anligger arkitektur i og med at det sannsynligvis er et valg som har noe å si for eksterne egenskaper. Dette er forøvrig også en del av designet, og derav følger at arkitektur er en delmengde av design.

Den klassiske arkitekturen – firmitatis utilitatis venustatis

I min noe vilkårlige og overfladiske omgang med klassiske verker er jeg funnet “De architectura” (“Om arkitektur”) av Vitruvius. “De architectura” er antikkens mest kjente referanse for definisjon av arkitektur. Den er inndelt i ti seksjoner og omhandler alt fra byplanlegging, materialkunnskap og vanntilførsel til bruk av maskiner. Vitruvius mener at en god bygning må etterleve de tre prinsippene firmitatis utilitatis venustatis som kan oversettes (av meg, via engelsk) som:

• Styrke (eller robusthet) – den skal være bygd på et solid fundament og bygd av nøye utvalgte materialer
• Funksjonalitet (eller brukbarhet) – gjennom en fornuftig sammensetning av dens deler slik at delene kommer til sin rett
• Skjønnhet – den skal ha et fint utseende og fremstå som en helhet der alle delene er proporsjonert i forhold til hverandre

Er dette prinsipper som også gir mening i vår bransje? Som jeg nevnte innledningsvis, er det lett å gå seg vill i alle arkitekturbegrepene. Fra nå av omtaler jeg “arkitektur innen informasjonsteknologi” kort og godt som “arkitektur”, og når jeg omtaler arkitektur i klassisk forstand som “bygningsarkitektur” eller “klassisk arkitektur”.

Klassiske prinsipper anvendt i vår hverdag

Styrke (eller robusthet)

For en bygning er det lett å være enig i at den må ha et tilstrekkelig solid fundament og at den må være bygd av egnede materialer. For et IT-system er ikke dette like intuitivt. Når det gjelder programvare (“mykvare”) skal denne være myk og formelig for å kunne imøtekomme fremtidige krav som oppstår gjennom systemets livssyklus. I motsetning til styrke i form av fasthet eller ubevegelighet, er “endringsvennlighet” (eng. “changeability”) en kvalitet som vi ønsker i arkitekturen vår. Samtidig er det sjelden mulig å ha en arkitektur som er åpen for alle mulige endringer, noen fundamenter må være fastere enn andre. Utfordringen består i å forutse hvilke endringer som er sannsynlig kommer og hvilke som er usannsynlige. Klarer man det, kan man sørge for at designvalg ikke påvirker endringsvennligheten i negativ retning.  Man kan muligens også snakke om at en arkitektur er “robust og slitesterk” i den forstand at den skal kunne imøtekomme nye bruksmønster og at den skal være skalerbar og anvendbar i ulike situasjoner. Jeg tør også påstå at jo lavere kompleksitet arkitekturen har, jo større er sannsynligheten for at den blir anvendbar i fremtiden.

Funksjonalitet (eller brukbarhet)

Prinsippet utilitatis er noe som i mine øyne er direkte overførbart til vår bransje. “Nytteverdi” er muligens et enda bedre ord for denne egenskapen. Høy nytteverdi oppnås ved at systemets ulike deler spiller sammen slik at hver enkelt del er formålstjenlig og virker sammen i en helhet. Ikke vanskelig å være enig i dette, utfordringen man har som arkitekt er ofte å sørge for et riktig utvalg av komponenter og integrere disse slik at de spiller godt sammen.

Skjønnhet

Skal vi anvende prinsippet om venustatis i vår hverdag, må vi kanskje ha et litt videre perspektiv en visuell skjønnhet. (Uten at jeg skal påstå at Vitruvius kun refererte til visuell skjønnhet.) Er skjønnhet noe som vi arkitekter vanligvis fokuserer på?  Burde vi? Og hva er “skjønnhet” i en arkitektur? I “Zen of Python“, som omhandler designprinsipper for programmeringsspråket Python, sier Tim Peters at “beautiful is better than ugly”. Dette hjelper oss kanskje ikke så mye nærmere svaret. La oss heller snu om på det og si at skjønnhet er det som behager og gleder folk, hva nå enn det er. Og hvem er folk? Jo, det er sluttbrukere, arkitekter, driftspersonell og utviklere (blant andre). “Vakker i sin enkelhet”, sier man ofte, og i mine øyne er enkelhet viktig i en arkitektur. Er arkitekturen enkel og lett å forstå, så er den “vakker i sin enkelhet”.

Som vi ser er de klassiske prinsippene for arkitektur absolutt anvendbare på informasjonsteknologi, og jeg tør påstå at de også gir verdi gjennom å hjelpe til gi innsikt i hva man bør vektlegge.

Moderne prinsipper for arkitektur

Hvis vi så forlater antikken og stiger inn i nåtiden så finnes det andre oppfatninger om hva arkitektur omhandler. Her er en liste fra “Beautiful architecture” som jeg syns er nyttig:

• Funksjonalitet – hvilken funksjonalitet som systemet tilbyr brukerne
• Endringsvennlighet – hvilke endringer kommer til måtte gjøres i fremtiden, og hvilke endringer er ikke sannsynlige?
• Ytelse – hva vil systemets ytelse være?
• Kapasitet – Hvor mange samtidige brukere skal systemet betjene? Hvor store datamengder skal det behandle?
• Økosystem – hvordan vil systemet samhandle med andre systemer i økosystemet det skal produksjonssettes i?
• Modularitet – hvordan deler man opp jobben med å utvikle systemet og i særdeleshet; hvordan kan systemet modulariseres slik at modulene kan utvikles uavhengig av hverandre og samtidig imøtekomme hverandres krav presist og enkelt?
• Byggbarhet – Kan systemet bygges som et sett av komponenter som kan implementeres og verifiseres uavhengig av hverandre? Hvilke komponenter burde gjenbrukes fra andre produkter og hvilke burde anskaffes fra eksterne tilbydere?
• Produktifisering – hvis systemet skal eksistere i ulike versjoner, hvordan kan det utvikles som en produktlinje?
• Sikkerhet – Hvordan kan informasjonssikkerheten ivaretas?

Denne listen inneholder en del fellespunkter med de vi fant hos Vitruvius. I tillegg tilføyer den en del punkter som er spesifikke for informasjonsteknologi. Jeg syns dette er en nyttig liste; den har et passe detaljnivå og er ikke for lang.

Oppsummering

Arkitektur omhandler helheten i et system, til forskjell fra design. Arkitektur adresserer eksterne kvaliteter, på ulike nivåer. Arkitektur innen informasjonsteknologi og klassisk arkitektur har noen felles prinsipper som bør vektlegges. I tillegg til dette har arkitektur innen informasjonsteknologi noen prinsipper som er spesifikke for fagområdet.

Use abstraction to reduce the impact of change

If a part of your system is prone to changes you need to isolate that part of the system to reduce the impact of change. This is usually done using some sort of abstraction. An example of this is the use of interfaces in order to be able to change the implementing classes of some exposed functionality without breaking the parts of the system that depend on this exposed functionality. The same way of thinking may be used to make your webtests less fragile. The key to this is to see your web pages as exposing functionality. The search page of google does for example expose the functionality of searching for a term or phrase.

Introducing Page Objects

The functionality of a page can be exposed to your tests using an object, a Page Object, that your tests interact with rather than the actual web page itself. The Page Object is like an interface to your web page. It exposes the functionality on the page while at the same time hiding the implementation details. This means that a test that exercises the search functionality does not know anything about the details required in order to search for something, that is that you need to locate an html element with id “q”, enter text into this, and then press a button with the text “Google Search”. Your tests only know that the page exposes functionality for searching after a phrase.

Abstracting google search functionality using a page object

So how does this look like in real life? Imagine the following test scenario:

Given that I am on the google search page
When searching for the phrase "webdriver"
Then a link to the project's home page should be present in the search results

The test written in JUnit for this scenario using page objects could look like the following

@Test
public void whenSearchingForWebDriverUrlShouldBePresentInSearchResults() {
	SearchPage searchPage = createSearchPage(driver);
	SearchResultPage resultPage = searchPage.searchFor("webdriver");
	assertTrue(resultPage.isLinkPresentInResults("http://code.google.com/p/selenium/"));
}

This test contains only three lines and is easily readable. A test exercising the same functionality but without using page objects is given below:

@Test
public void whenSearchingForWebDriverUrlShouldBePresentInSearchResults() {
	WebDriver webDriver = new FirefoxDriver();
	webDriver.get("http://www.google.com/");
	WebElement searchField = webDriver.findElement(By.name("q"));
	searchField.sendKeys("webdriver");
	searchField.submit();
	assertNotNull(webDriver.findElement(By.xpath(
		"//a[@href='http://code.google.com/p/selenium/']")));
	webDriver.quit();
}

Notice that the test using page objects is much more readable than the one without, and it is easy to capture the essence of the test scenario. Furthermore, imagine having 50 tests that all test various aspects of the search functionality. If the name of the search field changes to “x” all of your tests will break. In order to get them running again you would have to go through each test replacing “q” with “x”. Now, if you used page objects, all your tests would still break, but you would only have to make a change on place, in your page object, instead of all 50 tests.

Key features of Page Objects

The key features of page objects can be summarized as follows:

Methods represent services

The methods represent functionality exposed to the user on the page, such as searchForPhrase(“phrase”).

Hide implementation details

They do not reveal how the functionality is implemented, for example how you locate the search field or the button needed to be pushed in order to perform the search.

Do not make assumptions

Methods on a Page Object are neutral in the sense that they do not state whether something should be true or not. It is up to the users of the Page Object to make assumptions. The Page Objects only provide the ability to make assumptions, such as isLinkPresentInResults(“link”).

Methods return other page objects

This causes the Page Objects to reveal the flow through the application.

Different outcomes are modelled as separate methods

Because the flow of the application is revealed, different paths through the application must be modeled separately. When logging in to an application you would for example expect to be sent to different pages depending on whether you provided valid login credentials or not.

Need not represent an entire page

A Page Object may only represent part of a page, such as a login panel on a portal application that provides personalization.

Succeeding with Webtesting

There are of course other challenges of webtests and this is not the full story of how to succeed with webtesting. For more about the full story have a look at the slides from my presentation Succeeding with webtesting using webdriver at Free-Test 2010