Naked Objects Michael Persson, d04mpe Peter Exner, dt08pe8 2 mars 2010
Sammanfattning Naked objects är ett mönster som kan användas för att skapa en grundarkitektur. Tankesättet med Naked Objects är att eliminera den traditionella lagerstrukturen och istället skapa ett sammanlänkat. Vi har skapat en första iteration av Enduro projektet med hjälp av Naked Objects ramverket och tillsammans med olika mätvärden och våra observationer skapat en bild av Naked Objects stryka resp. svaghet för agila projekt.
Innehåll 1 Inledning 2 2 Enduro 2 3 Naked objects 3 4 Utförande och Observationer 5 5 Metrics 5 6 Slutsats 6 1
1 Inledning Inom mjukvaruutveckling har det länge funnits en strävan åt att återspegla användarkrav iform av olika strukturer som på ett enhetligt och inkapslande sätt representerar de entiteter som finns inom användardomänen. Tanken bakom har varit att på ett naturligt sätt fånga in logik och data till de objekt de tillhör. Inom affärssystem används ofta begreppen affärs- eller domänobjekt för att beskriva dessa entiteter. Objektorienterad programmering där attribut och beteende kapslas in i ett objekt är ett steg i den riktningen. För att dessutom hålla arkitekturen av ett system agilt och därmed utbyggningsbart är det av stor vikt att kopplingen mellan affärsobjekt hålls minimal [9]. Av denna anledning är det viktigt att affärsobjekten själva innehåller den logik som de representerar och inte endast blir till samlingsobjekt av data. En av anledningarna till denna separering av logik från data är enligt grundarna till Naked Objects uppkomsten av arkitekturer som delar upp system i skilda lager [9]. Naked Objects är ett arkitekt mönster som motverkar detta genom att automatiskt generera de lager som sluter sig kring affärsobjekten. Affärsobjekten blir på så vis direkt exponerade för användarna och genom detta utlovas ett gemensamt språk mellan utvecklare och kund samt kortare utvecklingstider då GUI autogenereras. Dessa egenskaper verkar dessutom falla väldigt väl inom ett projekt som använder agil utveckling. Ett gemensamt språk är en av förutsättningarna till att kunden kan kommunicera med utvecklarna och därmed medverka i utformningen av systemet. Genom ett gemensamt språk stödjs XP teknikerna Add a Customer to the Team och Develop a Common Vocabulary [6]. Den korta utvecklingstiden stödjer framtagningen av en första iteration(exploration phase), varifrån nya stories kan tas fram. Tidigare studier [7] av Naked objects pekar på att mönstret med fördel kan användas i utforskningsstadiet av ett agilt projekt, dessutom utlovas en kortare utvecklingstid av användarstories. Vårt mål med studien är att: skapa en första iteration av Enduro projektet i Naked Objects jämföra första iterationen mellan teknikerna lokalisera svagheter/styrkor med Naked Objects i ett XP projekt undersöka affärsvärdet av en första iteration i Naked Objects undersöka hur Naked Objects kan användas i PVG-kursen Rapporten avser att ge en allmän översikt av Naked Objects och hur naked Objects kan appliceras i ett agilt projekt. Rapporten behandlar och analyserar den empiriska datan som skapats under utvecklingen av projektet. 2 Enduro Enduro är ett skolprojekt, i PVG(Programvaruutveckling i grupp) kursen, vars syfte är att ett team datateknikstudenter ska praktisera XP metodik [6]. Programmet som ska utvecklas är ett tidtagningsprogram som kan hantera olika sorters indata. Hur mycket indata samt vilka funktioner som ska finnas sker enligt överenskommelse mellan teamet och kunden. Kunden är en lärare som agerar som slutanvändare och kund. Det är samma person som presenterar ev. önskemål och förändringar. Teamet utvecklar programmet under sex iterationer. I varje iteration ingår ett planeringsmöte samt en långlabb. På planeringsmöten skattas relevanta stories och därefter görs en prioritering av teamet. Det förs även en dialog med kunden om dess ev. önskemål. På långlabbarna utvecklar teamet de stories som kunden om teamet kommit överens om. På planeringsmötet delas delas det ut spikes. Spikes kan ses som en hemuppgift som ska göras på ca 4 h och varje teammedlem får en spike. Hädanefter refereras Enduro projektet som projektet och PVG teamet som teamet. 2
Figur 1: Figuren beskriver tanken med lagerstrukturen i Naked Objects 3 Naked objects Naked Objects är ett mönster som kan användas för att skapa en grundarkitektur. Tankesättet med Naked Objects är att eliminera den traditionella lagerstrukturen och istället skapa ett sammanlänkat lager Why develop multiple layers when you only need develop one? [4]. Se figur 1. Vid utveckling av affärssystem innebär en ändring på affärslagret oftast att även omkringliggande lager behöver ändras. I Naked Objects arbetar utvecklarna endast på affärslagret, omkringliggande lager såsom presentationslagret genereras automatiskt och på så vis undgås även att funktioner som normalt tillhör affärsobjekten hamnar utanför i ett annat lager. Mappningen av affärsobjekt till presentationslagret är direkt, attribut och funktioner som är definerade i affärsobjekten visas i gränssnittet. På så vis läggs fokus på utvecklingen av affärsobjekt och det blir självklart att placera funktioner lokalt i affärsobjekten. I Naked Objects finns det tre klasser huvudsakliga abstrakta klasser, AbstractDomainObject, AbstractFixture och AbstractService. AbstractDomainObject - Denna klass äver alla affärsobjekten ifrån. Affärsobjekten måste ha lämpliga metoder för att hantera affärobjektets attribut för att Naked Objects ska kunna utnyttja objekten. AbstractFixture - En fixture laddas först av alla klasser och kan ses som en form att setup klass. En fixture används för att fylla på affärsobjekten med lämplig data från t ex. en databas. AbstractService - En service är den klassen som publiceras mot GUI. Det är i serviceklassen som funktionerna bestäms och vilka funktioner som ska vara tillgängliga, publika, i GUI (högerklick i GUI). Genom att ärva från klasserna ovan får utvecklaren tillgång till en del användbara metoder t ex. ges det tillgång till samtliga affärsobjekt av en viss typ och vilken text/label som ska visas i GUI. Det finns även en del notationer som kan styra metoderna t ex. om en funktion ska vara synlig, eller inte, i GUI. Se exempelkoden. @Hidden public Contestant newcontestant(string name, int startnumber) { Contestant contestant = (Contestant) newtransientinstance(contestant.class); contestant.setname(name); contestant.setstartnbr(startnumber); persist(contestant); return contestant; } 3
Figur 2: DND(Drag n drop) GUI i Naked Objects Framework Naked Objects styrs väldigt mycket av en konfigurationsfil. I konfigurationfilen sätts vilka services som ska visas i GUI och vilka fixtures som ska laddas, vilka olika path:er som ska användas samt vilka användare som ska finnas. Det finns väldigt många inställningar, många outforskade, som kan sättas i konfigurationsfilen. Naked Objects Framework har stöd för användarprofiler vilket gör Naked Objects väldigt flexibelt och ger möjlighet att begränsa användare enligt traditionellt mönster, t ex. administratör och användare. För att sammanlänka affärslagret med databaslagret använder sig Naked Objects av Hibernate[2]. Mer precist används hibernate för att automatiskt generera en koppling mellan affärsobjekt och databasentiteter. Fördelarna med Naked objects är att: utvecklingsiterationen blir snabbare eftersom en stor del av utvecklingsarbetet genereras automatiskt. ändringar underlättas då de endast sker i ett lager och får genomslag i övriga lager. GUI genereras automatiskt vilket annars är en tidskrävande process. en gemensam terminologi utvecklas då samma namngivning används genomgående i de olika lagren Fördelarna vid agil utveckling med Naked Objects är: Strategisk agilitet [10], funktionerna är lokalisera de till affärsobjekten vilket gör utbyggnad enklare. Därmed stöds en iterativ utvecklingsmodel. 4
Operationell agilitet [10], det objektorienterade användargränssnittet får användarna att tänka i termer av affärsobjekt, operationer blir således inte en följd av knapptryckningar. Det automatiskt genererade användargränssnittet leder till en snabb utveckling där användarkrav snabbt omvandlas till ett körbart program. Det gemensamma språket bygger kring affärsobjekten, detta möjliggör att kommunikationen mellan användare och utvecklare blir effektiv. Naked Objects är implementerat i ett Open-Source ramverk kallat Naked Object Framework, förutom mönstret stödjer även ramverket automatisk generering av dokumentation. Generingen av användargränssnittet kan ske till olika plattformar.två av dessa DND(Drag n drop), se figur 2, och HTML följer med ramverket. 4 Utförande och Observationer För att på något sätt få en bra och rättvis jämförelse om hur bra Naked Objects ramverket lämpar sig för projektet kom vi fram till att vi skulle jämföra en första iteration mellan teamet och oss. Vi lät först teamet skapa den första iterationen genom att använda traditionell XP metodik, därefter utvecklade vi en egen iteration i Naked Objects ramverket som uppfyllde samma krav och stories. Under utvecklingen i Naked Objects observerade vi följande: Strukturen blev väldigt påtvingad, i Naked Objects finns det tre huvudsakliga klasser att ärva från: DomainObjects, Services och Fixtures. Detta leder till att man naturligt tänker i termer av affärsobjekt, i vårt fall fick vi affärsobjekten Förare, Starttider och Måltider som samtliga ärver från klassen DomainObjects. Inlärningströskel är väldigt hög - dokumentationen kring Naked Objects är till mängden omfattande och koncepten kring affärsobjekten är väl dokumenterad. Samtidigt brister dokumentation när det gäller att förklara hur datalagringen av affärsobjekten sker. Vi kunde av denna anledning inte dra nytta av ramverkets styrka i detta området Det saknas bra tutorials som steg för steg visar hur man skapar och visar ett affärsobjekt från grunden, det tog oss därför lång tid att att komma igång. Det automatiskt genererade användargränssnittet(dnd), se figur 2, är väldigt begränsat. T ex. är det begränsat på så sätt att det inte går att lägga till egen grafik så som bilder och grafer. Visserligen går det att utöka ramverket och utveckla ett eget gränssnitt, men då går en av fördelarna med Naked Objects förlorad. Vår utmaning har varit att implementera iteration ett av projektet i Naked Objects, ett för oss tidigare okänt ramverk. På motsvarande sätt ställdes teamet inför utmaningen att implementera Enduro projektet genom att använda XP-metodik. 5 Metrics För att jämföra Naked Objects med traditionell XP utveckling har vi tagit ett antal mätvärden på de två projekten. Vid utvecklingen av Naked Objects versionen tillämpades inte test first metoden, av denna anledning ingår ingen testkod från något av projekten. Mätvärdena är framtagna med hjälp av verktygen Metrics [3], Pmd [5] samt Chidamber and Kemerer Java Metrics [1]. 5
Mätvärde Naked Objects XP Antalet programmeringspar 1 4 Utvecklingstid total (h) 16 8 Arbetsinsats (h) 16 32 Antalet klasser 12 11 Antalet metoder 51 29 Antalet kodrader i metoder(mloc) 196 243 Varav GUI 0 45 Totalt antal kodrader(tloc) 421 412 McCabe CC, Max 6 13 NPath, Max 500 540 Coupling between objects classes, Max 5 6 Arbetsinsatsen, totalt antal utvecklartimmar som utnyttjades, talar tydligt till fördel för Naked Objects, på hälften av tiden det tog för ett team på 8 utvecklare lyckades vi ta fram ett program som uppfyllde samma krav och funktionalitet. Antalet klasser blev nästan identiska i båda projekten, detta var förväntat då antalet klasser är förhållandevis få i början av ett projekt. Antalet metoder i överstiger tydligt i Naked Objects projektet, detta beror till stor del på att man via Naked Objects mönstret är tilltvingade till att implementera getter- och settermetoder i affärsobjekten. De övriga mätvärdena bör med tanke på projektets storlek tolkas med stor försiktighet. Cyklomatisk Komplexitet(McCabe CC)[3], antalet olika vägar(npath)[5] samt funktionsberoende mellan objekt(coupling between object classes)[1] visade enligt vår mening inga större skillnader, de är till viss del beroende på hur mycket av arbetsinsatsen som tilldelats refaktorisering. Antalet kodrader i metoder pekar dock på ett intressant faktum, då GUI genereras automatiskt i Naked Objects utvecklade vi inget GUI vilket även ledde till ett lägre antal kodrader. Det totala antalet kodrader blev nästan detsamma, i detta mätetal ingår importer av bibliotek, deklarationer av klassattribut samt metodnamn, vi tror att kodrader i metoder visar ett mera relevant jämförelsetal. Mätvärdena bör aktsamt jämföras då förkunskaperna i java spelar en stor roll för samtliga utvecklare. 6 Slutsats Baserat på våra erfarenheter och observationer drar vi följande slutsatser om Naked Objects: Inlärningskurvan är väldig hög vid första användningen av Naked Objects. Av detta skäl vill vi inte rekommendera användningen av Naked Objects i projektet. Det kan däremot vara intressant att tillsammans med Naked Objects experter ta fram och diskutera en första iteration av projektet. Om kunskap kring Naked Objects redan finns i ett utvecklingsteam så kan Naked Objects med fördel användas för att ta fram en prototyp. Ingen GUI kod skrivs vid användning av Naked Objects. Detta ska vägas mot det faktum att det genererade gränssnittet inte blir anpassningsbar och av den anledningen inte kommer att passa ett projekt i längden. Naked Objects är mest lämpligt för projekt som är databasintensiva och inte fordrar stora krav på användargränssnitt. Sådana affärssystem kan dra stor nytta av att presentationslagret och databaslagret automatiskt genereras. Utvecklingen sker genom att affärsobjekt identifieras, hela tänkandet kring ett projekt sker i termer av affärsobjekt. Detta kan ge en stor fördel vid agil utveckling, kommunikationen mellan utvecklare och kund förbättras samtidigt som avståndet mellan stories och resultat blir kortare. För att dra större slutsatser om kodkvalité samt kodstorlek måste ytterligare iterationer av projektet implementeras. Även om antalet kodrader i metoder var färre är det för tidigt att dra slutsatser om detta även kommer att gälla i fortsättningen. Likaså bör kodkomplexiteten endast utvärderas efter flera iterationer. Samtidigt bör det även tas i beaktning att teamet fick en overhead pga. den kommunikation som krävs när åtta personer samarbetar kring ett projekt. 6
Referenser [1] Chidamber and kemerer java metrics - https://www.spinellis.gr/sw/ckjm/. [2] Hibernate - https://www.hibernate.org/. [3] Metrics - https://metrics.sourceforge.net/. [4] Naked objects - https://www.nakedobjects.org/. [5] Pmd - https://pmd.sourceforge.net/. [6] Chromatic. Extreme Programming: Pocket guide. 2003. [7] Heikki Keränen and Pekka Abrahamsson. A case study on naked objects in agile software development. In Hubert Baumeister, Michele Marchesi, and Mike Holcombe, editors, XP, volume 3556 of Lecture Notes in Computer Science, pages 189 197. Springer, 2005. [8] Michele Marchesi and Giancarlo Succi, editors. Extreme Programming and Agile Processes in Software Engineering, 4th International Conference, XP 2003, Genova, Italy, May 25-29, 2003 Proceedings, volume 2675 of Lecture Notes in Computer Science. Springer, 2003. [9] Richard Pawson. Naked Objects, Ph.D Thesis. 2004. [10] Richard Pawson and Vincent Wade. Agile development using naked objects. In Marchesi and Succi [8], pages 97 103. 7